"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do."
-- unsure; often attributed without source to information philosopher Ted Nelson
(I wrote this in 2001, and never developed it as far as I originally intended. So it might or might not be useful to anybody!)
I was motivated to write these guidelines for two reasons:
So, these guidelines document some "best practices" that I have accumulated over the years. The guidelines address the following concerns:
Some poor programming practices, like buffer overflows and memory leaks, recur frequently despite being serious and well-known. Security concerns often are a hacked-together afterthought rather than an important design element.
Many helpful development tools are available but not widely used, because programmers don't know where to look for them or how to get quickly started using them.
The guidelines are primarily targeted at developing C/C++ programs in a Unix-like environment. They reflect a preference for GNU tools. They are aimed at software packages that will be distributed to people other than the programmer. Trivial programs for the programmer's own use or the use of small group can simplify or ignore many of these guidelines.
First, to give specific definitions to commonly used terms: