Coding Standards

We've recently been lucky enough at our company to find several promising software engineers, some junior, some middling, and some fairly experienced, who are just now ramping up in order to contribute to the next release of our product suite. This good fortune is tempered by the fact that we find ourselves needing to literally dictate to these motivated, intelligent, and creative people how they should implement their ideas.

We do this in order to establish a reasonable commonality of expectation amongst our developers. "We should comment our code heavily, we should name variables clearly, we should...", yadda^3. These decisions are, of course, made for the benefit of the team as a whole as opposed to an individual developer but people tend to be reluctant to change especially if what they've done previously worked for them. Sometimes they can be so reluctant as to resent such 'temerity.' I don't think we've got to worry about that too much; however, as we've previously only informally laid out these standards it may be some of our tenured developers who find these strictures presumptive. In any case, some of the coding standards items are required compliances and some are simple suggestions, and none appear to be too outrageious with the possible exception of expecting our engineers to give variables easy to read (albeit more time consuming to type) names. I'll need to finalize this document next week and then the complaining (even some valid complaining probably) can begin.

Hopefully, the team will seem them in a positive fashion and as a synergystic methodology as opposed to a barrier or hurdle they must overcome. I'm also trying to keep this document from being a list of my developmental 'pet peeves' (with one notable exception, do NOT put C++ implementation code in a header file unless it is truly necessary -my debugger and I thank you.)