Coding Standards

Coding Standards

I cannot pretend that I am a big fan of having coding style standards. But most large companies tend to have them, and there is certainly a benefit to doing so. You can find Google's on the Internet, and I read it to my toddler to put him to sleep (easier than putting him into a child seat and doing a hundred blockies at 3am while wearing pyjamas; who doesn't love parenting?).

The advantage of a coding policy is a standardization of various activities and processes company-wide, which is something they really like in head office. The disadvantages include things like: (a) a focus on “busy work” coding rather than adding new user features, and (b) practical difficulties merging two different development procedures if you acquire another big company. Newly acquired startups will expend a fair amount of effort to conform to your standards, but they probably need to do similar activities to fix technical debt, anyway.

My preference would rather be that a company has a specific organizational group focused on software engineering excellence, with a focus on practicality, rather than dictate the “one true way” of programming. Coding standards are only one of the many issues for such a cross-company team to address. This is the idea of having an SEPG in your organization, which is kind of like a SEP field, if you know what I mean. So, it is a matter of tone and focus in terms of how high or how low to go in devising the coding standard for your project or organization.

Some high-level issues that could be addressed:

• Which programming language. (C++, of course!)
• Code libraries allowed
• Tech stack: database, app layer, UI, etc.
• Tools: source code control, bug database, etc.
• Naming: e.g., good APIs follow a naming convention that the developer can guess.

A coding style for C++ could specify a variety of factors about which of the advanced language features to use (or avoid):

• Templates
• Operator overloading
• Class inheritance hierarchies
• Namespace management

I'm really not going to suggest your coding standard document should address indentation, variable names, comments, and so on, but some of these types of documents actually do.

There is also value in specifying standard suggested coding libraries and interfaces:

• Basic data types
• Basic coding libraries
• Basic data structures (e.g. hash tables, lookup tables, etc.)
• Unit testing library/APIs
• Regression testing tools and harnesses
• Assertions and self-testing
• Debug tracing code
• Exception handling
• Testing and debugging tools

I could go on, but I won't.

• Next: • Up: Table of Contents • Buy: Generative AI in C++: Coding Transformers and LLMs

The new AI programming book by Aussie AI co-founders: AI coding in C++ Transformer engine speedups LLM models Phone and desktop AI Code examples Research citations Get your copy from Amazon: Generative AI in C++