Beyond coding standards

If you're a programmer, you'll agree that programming is hard. It's interesting, it's fun, but hard. There are many reasons: ambitious goals, complex designs, slow compilers, lousy debuggers, chatty colleagues, morning sleepiness and evening hastiness. But I think that one of the biggest problems is choice.

Writing and debugging 1000 lines of code is boring, but possible. Most often, though, somewhere near line 50 you have some choice. For a simple example: what should be used to customise class behaviour: virtual function, boost:::function member or a policy class? The decision can take more time than writing those 50 lines, and maybe more that writing the remaining 9950 lines.

People often don't like making decisions and either try to avoid them, or to cache the results. The local cache of decisions regarding relative importance of drinking beer and attending lectures is called "the meaning of life", and allows one to miss lectures without regrets. The cache of decisions about programming is called "coding standard".

Great, so what's the problem? Unfortunately, coding standards tend to discuss things like brace placement or using "m_" prefixes, and these are exactly the questions for which everyone have an opinion already. There's no need for help. Another problem is that recommendations are very specific. Using std::auto_ptr as return type of function is great, but that won't make you 2 times more productive. And if you've learned all the entries in a standard, and run into a new problem, the standard is no longer a help.

What is needed is a set of increasingly high-level rules, which can be applied everywhere. And they can be more helpfull than "use sound practices". For example, "Exceptional C++" says that each object must have one responsibility. That's rather universal rule, which can be used everywhere. Another possible rule is "consistency is important". This can be used to avoid using different identifiers for one thing, for using the same prefix for all member variables, for using references whenever possible, and in many other situations.

The difficult problem is how to validate the general rules. Even for very specific questions, reasonable people can disagree. Recently, Andrei Alexandrescu noted on the Boost mailing list that one library overloads the comma operator, which was considered bad practice. Half of posters agreed, saying that problems are likely, and the other half thought the problems are not likely. Nobody has shown an example, though.

Usually, when I find a bug I try to figure out why it happened, and write the cause to a file. This did not make all bugs go away, but I've learned something. The higher the level of a rule is, the more real examples it will need to be accepted. And while I'm trying to generalise my own experience, and will post something here, I'm waiting for a book which won't talk about braces, but about the real issues.