It’s a .NET Life

May 6, 2009

Throw Away Code (aka Spike Solution)

Filed under: .NET, Agile, XP — Tags: , , — david.yancey @ 7:06 pm

 

I’ve been talking with a few of my programmers the past few days about the concept of throw away code, asking them if they’ve heard of the concept, or if they’ve thought about implementing it on their teams.   All but one of them replied back to me with variations of “what a waste of time”, or “why would I want to code knowing I”m going to throw it away?”.

Spike Solutions:

Extreme Programming defines spike solutions as:

Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate.

When a technical difficulty threatens to hold up the system’s development put a pair of developers on the problem for a week or two and reduce the potential risk.

The concept of throw away code is to practice coding to solve a technical problem, or practice implementing various design patterns / practices.  When your done practicing throw the code away and either start over, or implement what you’ve learned from the practice session.   When you’ve reached the end of your session then throw the code away and start over your next session.

Have a goal for each session.  Setting a goal such as learning how to implement the strategy design pattern, finding a solution for a technical / design issue, or testing out a new testing framework will help you stay focused and meet your goal.

Keep your practice sessions short, I like to keep them between 30min and 2hours, but never more than 2 hours.  Going past your set time for your session often times works against you and causes you to loose focus on your goal.  I’ve also experienced greater difficulty in convincing the business in approving longer session times.

Combining these sessions with pair programming also provides a great means for knowledge sharing with your team members. Whether you need to show a new team member your software library / framework, introduce them to TDD, or learn a new design pattern this is another good tool for you to use to help reach your goals.

So don’t be afraid to throw away your code.  In fact I encourage you to implement throw away coding sessions (aka spike solutions) in your team.

February 4, 2009

Code Noise Part 2!

Filed under: .NET, Agile, Refactoring — Tags: , , — david.yancey @ 2:48 pm

Last time we looked at what Code Noise was.  This time we are going to look at good practices for eliminating code noise.

Clean Naming:

Clean names reveal intent.
Clean names reveal intent.
Clean names reveal intent.

The point I’m trying to get across here is that good clean names reveal intent.  So what do I mean by this?  Names should tell what it does, why its there, and how it’s used.  You should not have to add a comment to explain what the intent is.  This applies to variables, functions, and class’s.

Let’s take a look at an example:  Before scrolling down to the “clean” version of this example try to determine what the intent of this code is.  After a bit of study, you will determine what the intent is.

public List<int> GetThem(int num1)
        {
            List<int> myList = new List<int>();
            int num2 = 2;
            int num3 = 0;
            myList.Add(num2);
            for (num2 = 3; num2 <= num1; num2 += 2)
            {
                for (num2 = 3; num2%num3 != 0; num3 += 2)
                    if (num3 == num2)
                    {
                        myList.Add(num2);
                    }
            }
            return myList;
        }

Now take a look at this example we can see what the intent of function and each variable.  By taking the time to use better intent revealing names we can reduce the amount of comments needed and have cleaner code.

public List<int> GetPrimeNumbers(int upperLimit)
        {
            List<int> PrimeNumbers = new List<int>();
            int testNumber = 2;
            int checkNumber = 0;
            PrimeNumbers.Add(testNumber);
            for (testNumber = 3; testNumber <= upperLimit; testNumber += 2)
            {
                for (testNumber = 3; testNumber%checkNumber != 0; checkNumber += 2)
                    if (checkNumber == testNumber)
                    {
                        PrimeNumbers.Add(testNumber);
                    }
            }
            return PrimeNumbers;
        }

 

Exception Handling

Tip #1:  Avoid generic exception handling.

Okay now before you start spamming me with comments, emails, general hatred let me explain why.

Generally when we catch a generic exception its to take care of “unhandled exceptions”.  While we don’t want unhandled exceptions presented to the customer we don’t want to default to using Try/Catch blocks just to handle a generic exception.  When we handle an exception we need to know what we are handling and why.

Tip #2:  Instead of returning error codes throw custom exceptions.

Checking return codes for errors can cause unnecessary code noise .  Instead throw a custom exception and catch that exception instead.

Tip #3:  Wrap 3rd party COT’s exception handling in a local custom exception class.

Most 3rd party COT’s exceptions are meaningless to our applications.  It would be better to catch those exceptions together in a local class and throw more meaningful exceptions.

 

These are just a few areas to look at when coding to help ensure clean code.

 

Have fun.

 

David Yancey

Powered by WordPress