just because you give a man a shovel, doesn’t mean he is going to use it to dig, many shovels make good leaning posts for the lazy.

try {
/* my entire program that ignores exceptions */
} catch {
print(“something bad happened”);
}

>This is my pet peeve. Declaring a function to
>return void translates to “for all eternity I
>hereby declare this function will always
>succeed.”

This isn’t true for languages that provide exceptions. In fact, if your language provides exceptions, you should use them to signal error conditions rather than relying on the caller to check a status code, becuase they force the caller to deal with the error in some manner rather than just ignoring it.

Yes, about the profiling for speed. I would say this even stronger than you did, that in my experience most assumptions about what code is causing slowness are just plain wrong. Use a profiler, or put in your own instrumentation and get the facts.

C++ specific – make your destructors virtual by default. You may not remember to change the signature when you subclass three years later.

7.b. make sure your tools cooperate with and/or enforce your development process rather than fighting it.

8.a. if you have access to more than one compiler, use both for testing. different compilers catch different code issues.

9. in comments, document intent as well as behavior. this makes it easier for people who do read comments to understand how to write to the interface so that all hell doesn’t break loose if you change the behavior.

This is my pet peeve. Declaring a function to return void translates to “for all eternity I hereby declare this function will always succeed.” It is rare when you can actually make this claim and even rarer that it remains true over time. Save us all the effort, declare your function to return a value – we’ll add the error handing up front and then in six months when you update the function we’ll both be glad you chose the higher calling.

Your point is a really good example, by the way, of how lousy code begets more lousy code. Somewhere there’s a guy writing a kernel device driver who wants to write good code, but because some nameless kernel *cough*LINUX*cough* is dripping with garbage and won’t build with -Werror -Wall, he basically _can’t_ use the robots to help him write good code.

I feel sorry for that guy. I bet he wishes that the people that wrote those kernels had done their jobs properly. If they had, he’d be able to use better tools to help him write better code.

At least when we could fix the bugs…