Least Common Denominator Rules

(Extracted from BadCodingStandards)

The comment was made on the BadCodingStandards page that "I've been told not to use a given language construct because a maintenance programmer might not know what it does."

This is not such a bad rule, particularly if you're working with a complicated language like CeePlusPlus. The CeePlusPlus standard library is very powerful, but also very large. Each organisation needs to have some feel for the level of understanding it can expect from its developers; it's not realistic to expect them all to be familiar with all of the idioms allowed by C++. Coding at a level which can be maintained by your peers, while also working to help the whole team to develop its skills to improve that least common denominator, is just professional. Insisting on using a language feature for purely technical grounds does not usually indicate a mature approach to software development.

Of course compromises are possible; you may once in a while find that the extra technical merit justified writing some code which will be non-obvious to other developers on the team, and choose to write it anyway with a comment block to explain why you've done so.

Unfamiliar constructs are not the only things that obfuscate code. If you're going to take a "least common denominator" approach (I would like to call it a "mashed carrots and pureed peas approach"), then please be sure that all the other obfuscations have been removed first. Then consider the construct on its own merits without trying to anticipate who will have to maintain it, since you probably can't guess that with any accuracy anyway. Is it good design, or is it software snobbery? Leave the ego in the car trunk. Then, go with the best design and let the maintenance programmers take care of themselves. Chances are, these people are capable of chewing on real code, given the chance. And finally, dear programmer, give them the chance by adding only as much clarifying commentary as you would require if you were the same maintenance programmer.

The "rule" of least common denominator will taste better when folded gently together with the rule of gold.

It may help to have a central document or reference explaining "stuff you are expected to know". If you are the first person to use a new idiom - say, to implement C++ assignment in terms of swap - you can do so with a clear conscience provided you update the central documentation.

The documentation would live with the house style sheet. It might mostly consist of references to explanations by other people - the relevant chapters of HerbSutter's ExceptionalCpp, in this example. You might want to discuss idioms with the rest of the team before deciding whether to document and use them.