Pointers, References and Values by Mike Crawford Continued...

The Main Goals

The goals of the style I advocate are to write correct, bug free, high performance and maintainable code. It must be easy to work with during development.

C++ is an abomination to society, and is doubtlessly responsible for hundreds of millions of lost hours of productivity. -- Space Monkey, posted on Kuro5hin

Sometimes these goals require a choice among trade-offs; in general one must prefer correct and bug-free, then maintainable and easy to develop, and finally high performance.

You may be surprised to hear me list performance as the last thing to be concerned about in designing one's software, but I'm not advocating slow code; rather, I'm acknowledging that most of the code one writes has little effect on the ultimate performance of the product. This is the 80-20 rule; 80 percent of the runtime is spent in 20 percent of the code - but you are likely to find that most of the complexity is in the 80 percent of the code that does not affect performance significantly, so you might as well make it maintainable rather than trying to make it fast.

It is almost always possible to write nice code that runs fast. This requires experience, judgement and skill. That's part of why I am writing this, to help you get to that point, and to solicit comments from readers as to how I can improve my own technique.

You see, this article represents my own technique as it stands at the time of its writing (or rather, the ideal I strive to achieve in my work - in practice I sometimes fall short), and I hope that if there is something I can improve about the way I write my code then you will point it out. As a consultant who writes entire products largely on his own, I do not generally have the benefit of code reviews, but I am able to critically revise my older code as my standards improve - so in this sense by giving me feedback on this article you are also helping me to write better code for my clients.

I feel that the opinions expressed in this article serve as a better set of coding standards than those I usually encounter. Most coding standards used in industry either nitpick about how to name variables and arrange curly braces (without contributing in any substantial way to the resulting programmer efficiency, code quality or speed) or forbid the use of "advanced" C++ language features that the ISO C++ Standards committee put into the language for extremely good reasons - features without which it is not possible to write correct or efficient code. (A better approach would be to require junior programmers to learn the advanced technique, and to provide training to help them to. At least buy good books for the company programming library!)

My article does not cover everything that should be addressed in a coding standard but I assert it is a good start.

I'm also finding that writing this article is helping to clarify my thinking. I would encourage you too to write about the things you want to understand, not just the things you know about. (It was my experience as a teaching assistant in college, both in computational physics as an undergrad at CalTech and in physics lab as a grad student at UC Santa Cruz that teaching even basic subjects does a lot to sharpen one's understanding of a topic. You may think you understand a subject - but then try to explain it to someone who doesn't understand it well. Then you have to get really clear and explicit on your understanding; just having a feel for the subject won't be sufficient.)

next button previous page contents all programming tips titles

Copyright © 2000, 2001, 2002, 2005 Mike Crawford. All Rights Reserved.

One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light