“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away” - Antoine de Saint  Exupéry. If you’ve ever invited me do some pair programming with you, you probably have a good idea what this quote is all about. I often wind up asking questions like:

• Why do you need this boolean named retVal? Could it be eliminated the use of early return statements?
• Is the else clause in this if statement necessary? Could it be avoided with a return statement? Or break/continue in a loop?
• I noticed that this method has parts that are nested five levels of braces deep. Is there anything we can do to reduce that?

Two recent posts Spartan Programming (Jeff Atwood Coding Horror) taken from the Spartan Programming page on the Technion Wiki and Life After If, For and Switch (Scott Hansleman Computerzen), have reminded me of this subject.

Most of the Spartan ideas make sense to:

• Minimize depth of nesting of control structures
• Minimize the number of lines occupied – the idea being its easier to make sense of a method if its all on one screen. I would prefer that most methods be < 10 lines long. Some people read this suggestion to mean all blank lines should eliminated. I would disagree preferring to use blank lines like paragraph breaks, they indicate we’re changing gears.
• Minimize Token and Character Count suggest removing braces etc. – i.e. remove every non-essential character. I think these measures can be harmful and wouldn’t use them.
• Minimize the number of Parameters to a method and avoid the use of out params.
• Reduce the number of Variables – a number of excellent techniques are shown. I disagree with only two: the use of ternary operator and encouraging the use of very terse variable names.

My additional rules:

• Booleans make bad parameters. If you have method that has doStuff(realParam, true, false) – how does someone reading the calling know what true and false mean. At the very minimum use enums with meaningful names.
• One letter variable names like i,j,k and e come from the early days of Fortran where variables were 1-6 characters long. With so few characters its not surprise that common convention dictated that i,j,k were loop/index variables. We’ve come a long since then – use names that while concise get the point across.
• Rather than for(int index = 0; index < size(); index++) use Java (or .NET’s) foreach. They save an unnecessary indexing variable.
• Check arguments at the start of any public or package level method and after that assume they’re right.
• Minimize the use of instanceof – as your class structure grows these will be hard to maintain. More on this in up coming post.
• The if/switch statement you don’t write is one you don’t have to test.

So next you invite me to pair program at least you have an idea about some of the questions I will ask.

If you enjoyed this post, subscribe now to get free updates.

7. Case Studies

Credit: this is based on material from "10 ways to screw up with Scrum and XP" by Henrik Kniberg. Personal Experience: Mark Levison.

If you enjoyed this post, subscribe now to get free updates.