Simple Code Makes Good Software

A terrible week behind! After being privileged to work with WPF, I had to concentrate on fixing nasty bugs and adding requested new features to a “nearly finished” project we have been coding with six other developers. I felt *so* guilty because all I could do last week was to add more code lines and if statements to these sources my colleagues already have decorated with myriads of ifs. Sometimes it saves my day if I manage to reduce a prolix code passage into one line of just-to-the-point code. Last week there was no such day.

Every if statement we write makes our future life more miserable. The more ifs your code contains, the harder it is to grasp and maintain. If a logical inference doesn’t fit on one screenful of code, it is likely that a colleague that is going to maintain your code will not get your idea and only makes it worse with new ifs.

Ever had this feeling that the world would be a better place without if statements? When you write an if, your code “depends”, it’s contingent. Sometimes you can never be sure which branch of your code will actually execute. On the other hand, a code passage with no ifs can be thought of as necessary – it is always executed just the way you wrote it. The worst if is the one you write “just in case” when you have no idea what the actual situation will be when your code executes.

There are religions and even actual people that believe everything in the world was predestined – God needs no ifs. Being a mere mortal I must admit that I don’t know everything in advance and hence need to adapt to alternate situations with ifs. But there are things we know, and based on these things we must try to comprehend the world around us and express it as clearly and plainly as possible in our code. If you want to obscure the idea behind your code, write as many if statements as possible!

Let’s take an example! This is actual code I found on a project a few years ago. Based on a given sum value, it calculates the check digit of a Finnish bank reference number:

Unaware of the existence of this code, I wrote my version like this:

Look Ma, no ifs! To be honest, one if statement doesn’t make the whole difference here, and the first code line already shows that the author of CheckDigit_a has not comprehended the real idea behind this calculation. At the end of the code, it is not Destiny that decides whether the value of sum is 10 or not. It is something that can be calculated, and whatever the value is, it is necessarily what it is, not contingently. Once we are given a value for sum, the return value is implied and fixed – there is no room for hesitation, no ifs left!

Now we come to the point: Using an if statement is OK and even necessary when the condition is genuinely contingent, i.e. it comes from sources like user input, a value in a database column etc. When not, you should first consider saving one if and think whether the situation could be handled otherwise.

Since we cannot totally live without if statements, I would like to suggest that in order to keep the total number of ifs as low as possible, programmers should pay a fine for every if they write. If you want to have something left for the payday, consider the following:

• Use arithmetics, character functions etc. where possible!
• Try to reduce the amount of nested ifs by making an analysis of your conditions. Using a pencil, a piece of paper, and truth tables is a good method when the situation seems too complex to grasp. This way you will probably be able to combine several if statements into one and perhaps even find a branch that will never execute.
• Use the ?: conditional operator for atomary conditional situations. Logically it is equivalent with if, but compact as is it, it is easier to perceive as one logical unit so that it does not blur the larger if construct it might be part of.
• Use the switch statement instead of if .. else if statements where possible.
• Don’t use if like duct tape! It might look like an easy solution to add just one little if, but analyzing the code a bit further might produce the real solution to the problem.

If your project shows a tendency towards an ever-growing number of if statements, there must have been something wrong at the very outset. Use cases might have been forgotten or all possible situations were not taken into account in class design. Or maybe the design was too complicated because it didn’t hit the target: You needed a nail file but you designed a Leatherman.

“Well planned is half done” goes the common saying, which we could turn into “Badly planned needs more and more ifs”. When your code is becoming bloated with ifs, it could be still possible to save in the total amount of work by redesigning your application. In real life this is hardly possible because somebody would have to admit that there was something wrong with the initial design, so all you can do is to learn from your mistakes, try to get rid of the project, and to be wiser at the next project, if there is going to be a next project!

Back in the 80′s there were a breed of satiric texts titled like Real Programmers Don’t Use Pascal circulating around Usenet and photocopiers (see Wikipedia or do a web search on this title). Since then, things like OOP, CORBA, COM, and AJAX have been among the major issues that Real Programmers do or don’t use. What remains, however, is that programmers are supposed to write code – right?

So if you are a programmer, you should write as much code as you can because that’s what you are paid for. The more code you write, the better a programmer you will be. The plenitude of your code lines ensures your place in the Programmers’ Hall of Fame!

Not quite so, or, rather, not at all so! In fact, what you are paid for is implementing functionality, not writing code, which is just the necessary evil to accomplish your primary mission. Believe me, even you could write bugs sometimes, and the more code there is, the more bugs there will be. And because nothing is invariable in this world, somebody has to maintain your code after you have finished with it. Whether it is yourself or somebody else, maintaining 10,000 lines of code cannot be easier than maintaining 1,000 lines of code however beautiful those 10,000 lines might ever be.

So how to become a better programmer and write less code? That’s what this blog is trying to figure out. In forthcoming posts I will share my recipes how to utilize the .NET Framework to implement more functionality with less code. And even if you are not a .NET programmer, you might find some posts in this A Craft and an Art category at least intriguing if not downright interesting.

Be my guest!