Everywhere you look and turn, our everyday lives are governed by principles and rules, even if only unspoken or informal (dropping in on another surfer’s wave comes to mind). The world of programming is no different, as many codebases are likely to have more than one programmer over a lifetime. In order to make life easier for others, many programmers follow the principles of “good code”. But that begs the question: what exactly is good code?

To tell you the truth, there is no definitive answer. The concept is subject to many different interpretations, depending on what language is used and how a person has been taught. So, to celebrate the fact that the world didn’t end in 2012, we’re starting 2013 with a short series of posts on what “good code” means. Over the next five weeks we’ll explore five aspects of code that should really be fundamental to code being described as “good”.

Much of the following series is built upon Sara Falamaki’s talk, entitled “Happy Hackers == Happy Code”, which Eric attended at Linux.conf.au 2010 in Wellington.

Feature One: Good code should be correct.

We’ll start this series with a nice and easy assertion: that your code should be correct. What does correct code mean? It means that, given a set of inputs, it creates the expected outputs. This may sound incredibly obvious, but it’s overlooked with surprising frequency. There are two things that a programmer should keep in mind: What is this program meant to do? And how can I confirm that it’s performing correctly?

Ensuring the program meets the requirements can be as simple as keeping a checklist, and possibly a table showing a variety of inputs and their expected outputs. Frequently, something more formal like a Statement of Work is required, and when developing larger systems an even more in-depth description will be necessary. But at very least, a checklist of required functionality is a great way to make sure you’ve addressed all aspects.

On the other hand, a programmer might get carried away and create something that far exceeds its’ intended purpose; this is known as software bloat. Jamie Zawinski was responsible for popularising a phrase now known as Zawinski’s Law of Software Envelopment: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. If your code doesn’t need to provide a particular function, seriously consider whether adding that function will be beneficial or not. Adding unnecessary features will slow down delivery, introduce additional bugs, and confuse your users.

So – be sure to take the time to review what you’re trying to do. Keep a checklist. Consider it carefully before adding new features. Make sure you know what “correct” is in your scenario. Keep a table describing what a “correct” response would be for a given set of inputs. Gain feedback from others. And finally, ask yourself – “Does this line up with what I want to achieve? And is it giving me the results that it should?”