C Programming Commandments

I read a nice blog entry by Henry Spencer entitled “Commandments For C Programmers”. Some of them did not seem to be as important as others. However I took note because even though I am a C++ programmer, my style is more of a C programmer using a C++ compiler. I thought I would review some of the finer points of the commandments.

Henry recommends all C programmers run lint. Well that sounds like great theory. However I think I have maybe ran lint once or twice in my life. Maybe that is why we get array out of bounds errors now and then. And we also have some dark memory leaks in our code. Lint just sounds like a UNIX or command line type of thing. If I had a Windows GUI version, I bet I would make use of the tool more.

Another commandment is to check for NULL. Now this is one that I heed pretty closely. It is no fun when you try to de-reference a NULL pointer. Most code I write checks for NULL. In fact, I like to validate input parameters first in each function. And that means checking if any input pointers are NULL first.

A tough commandment to follow is to check return error codes. Yes I know this is crucial. However I normally code the case when functions do not return error codes first. Then if I have time, I got back and code in the paths for errors. You know how it goes. There is often not enough time to come back and do things like this.

Here is a commandment I have not heard about before. Thou shalt make external identifiers unique. Or you should at least make the first characters of long identifiers unique. Normally I figure that if the linker can resolve the externals, you are good to go. But that might get wack when you are writing a lot of code. I imagine you could get confused if there were different externals with the same name. Point is taken.

Obviously there were 10 original commandments. I have only reviewed a couple here. But I think it would be best to start small. If I tried to implement all 10 at once, I would give up too soon. Obey the commandments.