Programming is a difficult art to do well. I don’t mean the high level design or the specification of implementation patterns to use, I mean the actual “let me type up the implementation of this single procedure” effort. The problem lies in the need to have both structured, repeatable, consistent patterns of consideration and thinking, while simultaneously having a set of mental processes that lend themselves to innovation and unconventional insight. There’s the added difficulty caused by the fact that programming is often iterative in nature … you might add the portions of the code here, expect there to be interaction over there, and have to come back here to change things around based on behavior and expectation there.
Setting up a template of things to consider doesn’t work for many reasons, not the least of which is that, for the template to be useful across the board, it would have to be so generic and abstract that the concrete specifics of how to use it in a particular circumstance would allow the programmer so much flexibility that he’d dismiss the template entirely (which he would be inclined to do, since a template of what to think about would be offensive to him and his expensive training). Besides, if you have a template of steps to consider, you allow yourself to be constrained by that template, and innovation suffers.
Frankly, there is no solution. However, there are things that can be done to improve the situation by nudging the programmer’s mind in such a way that he considers certain aspects as part of his normal (and possibly unique) programming manner. The key is language and its use.
Words are referents that point to concepts. When you use a word, you’re indicating to a person that they should consider aspects of the concept. Multiple words might refer to the same concept, but indicate that different aspects of the concept should be considered relevant (this is one of the reasons that accurate use of language is important to unambiguous communication.) The structure of the language can also indicate a particular contextual framework in which the referred concepts should be evaluated.
Similarly, if you force a programmer to consider the language he is to use, or the structure he is to use, you can nudge his thought processes in such a way that he considers a particular necessary aspect of coding that he might otherwise overlook. As such, the person responsible for establishing a company’s (or API) coding style must consider areas in which he can provide this nudge. I’ll provide a few examples (please note that these are _examples_, and I will not enter into a debate about whether my particular example is the right or wrong way to do things.)
Classes, in general, reflect a conceptual entity. Therefore, classes should be named with the noun or noun phrase part of speech. By doing so, the programmer is forced to envision the thing and its intended context. Not only does this cause the programmer to more thoroughly evaluate that context (project business processes) allowing the team to identify deficiencies in specification, and also allows him to identify a meaningful hierarchy of related concepts such that a class hierarchy can be defined, but it also makes it easier for him to keep a mental image of the entity being modeled in mind as the coding proceeds.
Properties and methods have their own requirements and naming styles that can lend themselves to better development style. I’ll address these in the comments if necessary, but otherwise I’ll leave it as an exercise to the reader.
The Microsoft Visual Studio environment allows a developer to construct code “regions”, which are just delimited areas of code identified by a common name (with the ability to collapse everything down to a single node identified by that name.) If the coding standards require regions based on the access type of a particular property or method (e.g., #region Protected Methods), that reminds and encourages the programmer to evaluate what access level is actually appropriate, since recommended practice requires that you use the most restrictive that is reasonable.
There are times when resources must be closed or explicitly released (in the case of interacting with unmanaged code or GDI objects, given a few Microsoft GDI leaks), but programmers will frequently forget to consider this. If your coding style always requires that every code block be put in a Try … Finally structure (given that the Finally block is usually where you want to do that kind of clean-up), then the programmer is reminded in every procedure that he should evaluate whether that kind of clean-up is necessary. You don’t want it to be a Try … Catch or Try … Catch … Finally block, because this would encourage the programmer to unnecessarily handle exceptions, and this is not recommended practice.
Keep these techniques in mind, and consider them when documenting your own coding standards guides. Comments of other suggestions welcome, of course.