What Is Good Code?

Reginald Braithwaite is in search of what really matters in good code. I am sure many programmers are in the pursuit, so take time to read the entire piece.

Another view, the one I am promoting here, is that it isn’t about removing symbols, it’s about communicating something about the underlying relationships. Even if your language is so crufty that example two is longer than example one, it’s the right thing to do if the calculations are the same for a deep reason, if you are trying to communicate that they will always be the same.

That being said, my experience is that when a relationship exists, the code that clearly expresses it usually winds up being shorter than code that does not express it.

I have come to look at two different aspects of code:

• How well does it address its purpose and constraints
• How clearly does it indicate the problem it is trying to solve, which has resulted from my belief that software works best as a solution.

Software code usually embodies the solution, not the problem; and there I think lies a problem. Good code should express the problem it is trying to solve along with the solution. I think that even comments should be used for this, if the code cannot express it. Otherwise, under multiple hands, the code gets mauled because there is difference in understanding of the problem.

I am not sure whether this results in shorter code or easy-to-read code. Ease of reading code is subjective, we really cannot generalize it. In fact it is something that is particular not only to the programmers but even the project and its constraints. Good code should aim at building a better solution, and for that it is equally important to convey the underlying problem as well.