Coding conventions and non-standard standards

Coding conventions and style is probably programmers’ most fiercely-contested topic, and also the least-important. At the end of the day, as long as the compiler can read your code, and you can read your code, you’re fine. But consistency is good, so many organisations have rules on what their code should look like. These rules answer questions like, do braces start on their own line? Do we prefix private class members? Do we use CamelCase or underscores to separate words? And other such matters of great importance.

Deciding on these rules can be quite a nightmare, as everyone has their own personal preferences which they believe are superior. A lot of arguing can ensue. When deciding on what coding conventions to use, good standards can be found with:

• The language’s authors
• Application frameworks and libraries that you use a lot
• Respectable groups like the GNU project or Mozilla

Bad conventions come from:

• Other languages
• Long-standing tradition and sacred cows
• Other vendors’ implementations
• Non-programmers

My best recommendation is simply to go with the flow and use whatever style is recommended by your language’s authors and tools. If you’re writing a program in C, use K&R. If you’re using Java, use Sun’s Java conventions. If you’re writing C++ with Qt or some other framework use their standards, otherwise use the STL’s. For Microsoft T-SQL use the style generated by their SQL Server client tools. If you’re writing .NET code it should look the same as the Base Class Library. There is nothing wrong with these standards, and any deviations will simply require extra work to implement, like changing defaults or modifying generated code to match your company’s non-standard standards.