A note on coding style
I have never understood why the simple decision about coding style erupted into such a holy war amongst programmers. The majority of these fierce cries and complaints attack other coding styles and proclaim their own style as something of a ‘silver’ bullet. And yet, these comments have the grammatical adeptness of a three year old.
This makes me think that the majority of this holy war is fought between the mass of younger programmers, who unfortunately become involved in such meaningless debates.
Of course, the majority of programmers will toy around with different coding styles, in terms of tabs or spaces, indentation size, brace style, and whatever other quirky convention the human mind can come up with. I too did this, messing around with GNU style, K & R style, and KDE style. If at all relevant, my favourite of these was the KDE style (and by KDE style, I mean the style dictated in their Kdelibs policy).
I soon concluded that putting so much emphasis on coding style was detracting from the main point of coding itself. When you code for another project, it’s likely they have their own policies in place regarding coding style. And, if you’re going to be the only programmer reading your code, why bother trying to decide which is the best coding style? It’s like trying to decide which date format is better: YYYY/MM/DD, DD/MM/YYYY or MM/DD/YYYY. In the end, they all mean the same thing.
My recommendation, therefore, is to pick a coding style that is as simple as possible; no quirky conventions, no exceptions, just straightforward rules. Perhaps my favourite example of this is the style commonly known as the One True Brace Style. It’s simple and legible; that’s what we use coding style standards for, right?
If you complicate your own coding style too much, when you end up work on a foreign project you’ll find that you become frustrated with the standards that are in place: ‘why, these uncultured monsters break all of my coding rules!’
If you put that much emphasis on coding style, you need your priorities checked. And while you’re at it, take an OCD test. In the land of the programming gods you will find peace; there are no holy wars fought over such trifles. After all, they are gods. They know what is right and wrong.
Down here, where every just-turned-twelve programmer argues and cries over coding style, just try to remember what is important. Not only will you be doing yourself a huge favour, you will also be distinctly separate from the lowlife programmers fighting more holy wars than quashing bugs. It is only then that you can smell the roses, realise the more important aspects of programming, and become a true master of your craft.
