Programmers and programming teams should strive to use a reasonably well defined and consistent set of coding standards in their projects. These typically include rules for notation (use of case and special characters in identifiers, etc), style (layout of language elements within the source code), and idioms (specific usage of language features).
The benefits of a clear and useful coding standard are twofold: make the code easy to read and understand even in the absence of code inspection tools or previous knowledge, and encourage the creation of code whose performance and functionality are safe, predictable, verifiable and maintainable.
Programmers tend to be fairly vocal and strict about defending their preferred set of coding standards (whether they are equally strict at adhering to these standards varies a lot). This often leads to endless religious wars where opinions and personal experiences are presented as facts or universally applicable ideas. But, if widely varying sets of standards have proven to work in different projects, there can’t be a universally “best” standard?
Of course there isn’t. Duh!
There are bad practices, good practices and best practices. Bad practices (for example, lack of error checking) can be considered to produce universally undesirable results, whereas best practices (for example, strict const-correctness) should yield better code regardless of the circumstances.
The thing is, most decent standards offer mostly a collection of good practices. The value and applicability of these is relative to the context in which they are used, and as such can’t be considered universally valid or invalid. Different projects and different programmers have varying requirements and levels of expertise. Programmers naturally tend to restrict and partition any problem space into manageable subsets. Divide and conquer, so to speak. However, the huge scope of what defines the context of a programming task, often leads to implicit and biased assumptions about what is practical, what is relevant, and what is plain habit.
Being exposed, using and adapting to different standards is, in my experience, one of the best ways to gain insight into what defines the context of a project, and what works best in different situations.
John Lakos’ “Large Scale C++ Software Design” is one of the classic books touching this topic, but there are few freely available online references. I was happy to come across this coding standards document in Bjarne Stroustrup’s homepage. It is a very long but enjoyable exploration of a C++ coding standard that is widely different to the one I regularly advocate and use. Every goal, concept and rule (and there are many) is described and justified in a very concise manner. All of them make a lot of sense.
Being safety-critical is an often desired quality, but rarely a top priority of games software. That is probably a good place to start when comparing that document with your own context and coding standard. Enjoy the ride!