Programming Style

Does it really matter what the code looks like? The short answer is an emphatic ‘yes’.

It matters because ultimately writing code is about discipline and details. If the code is just slapped together, really messy and there are issues like extra blank lines or extra variables laying all over, it reveals an awful lot about the author. Perhaps they were in a huge rush or even a panic. Maybe they are just lazy or don’t care. Maybe they really don’t understand what they are doing. Any which way, their state-of-mind while doing the work was such that they lacked the self-discipline to clean up their work and thus were probably not particularly good with playing attention to the all-important details either. Messy code is almost always fragile and usually a bug fest.

Code is basically knowledge and intelligence encoded into a sequence of steps for the computer to execute. It is only as smart as the programmer that wrote it, and it is only as flexible as they conceived of the runtime environment. If the programmer’s style if haphazard or their thinking muddy, then the code will suffer the same faults. If however, the programmer’s understanding is crystal clear and they grok the environment, then the code will stand up to a lot and keep on working.

Just getting something to barely work for a extremely limited set of circumstances is not good enough to be considered professional quality. Working code has to work correctly for all circumstances; for all inputs; for all changes in the environment. It needs to be able to stand up to the full range of things that happen in the real world. If it doesn’t, that’s an indication of a lack of quality.

What experienced professional programmers always come to understand is that quality starts in the code. If you want a beautiful system that is a joy for the users, then the code underneath needs to not only be smart and well designed, but it also needs to look marvelous as well. The ‘platinum’ standard of coding comes from taking a complex problem and making the code look simple. Elegance comes from both the readability and the underlying skill used to make the answer look obvious. A well-written piece of code hides the messiness of the details carefully. It misleads a reader into thinking it took just a fraction of the time to get written. It leverages abstraction to avoid redundancies, but not at the cost of becoming obfuscated. It basically takes the knowledge of the programmer and encapsulates that into a small, tight region of the system that works correctly and makes it easy to extend later. It draws clean, hard lines through the problem and then ties them up with the lines in the solution. And because it is easy to see its sole purpose, it makes it really easy to detect and fix bugs. Quality software comes from quality code.

But it is not just quality that is affected by bad code. Testing, bug fixes, and support are all heavy drains on software development. Work spent in these areas is work that is no longer available for new development. Crappy-code bugs are way harder to find and fix, so as a consequence they chew through more resources. It actually costs more to write bad code than doing a good job the first time around, line for line.

And often projects get caught up in a vicious cycle of coding fast and recklessly then loosing too much time dealing with the inevitable problems, causing them to go right back to fast and reckless again. That type of cycle feeds back into morale, and the whole project does a slow spiral down the drain.

As for programming style, mostly it doesn’t really matter which conventions are chosen. Some conventions do make improvements in clarity or readability and help to make inconsistencies more obvious, but so long as all of the code is consistent, it can always be refactored to a better convention at some point.

Getting all of the variable names the same, laying out the lines with the same whitespace formatting and finding strong conventions for naming core parts like methods and objects establishes a strong foundation for the code. Normalization and abstraction help to either hide the details or put them forth in a way that inconsistencies are noticed easily. A solid architecture decomposes the system in a way that makes it easy to trace bugs quickly back to isolated parts of the code base. All of these things help in reducing the number of bugs, and also reducing the time it takes to fix them. And because of them, it opens up more time and resources for new development.

Building a high quality software system always means playing close attention to the millions of details floating about the project. It is not enough to just hack through the work, it is a detail-oriented process, which often needs great time and patience. All development projects come with outrageous demands and too little time, but being sloppy doesn’t help with these issues. Part of the great skill involved in being a professional programmer is the self-discipline to do the right thing, even under intense pressure. Sloppiness and short-cuts, while tempting are just putting off today, what will always cost more in the future. If the goal is quality, then that has to percolate into every tiny detail. Fast and cheap is always crap in software.