Gray Watson Personal Thoughts 2002.07.03
The 6 Cs of C Coding

[ Ok. I am officially on a roll. I've done 4 thoughts pages in the past 2 weeks. ]

[ I've added to this page a copy of the Lycos coding guidelines from my company in 1996. ]

I've been meaning for some time to document my programming "morals". These are the things that I feel are important characteristics of good code and good coders. In doing employee reviews recently for the guys on my team, I found myself stating over and over again what has become the 6 (or more) Cs of C programming. Most of these apply to other languages of course. Yes, I know, there is nothing here that is new or that hasn't been said before.

1. Correct -- Code should not contain bugs. Duh. This means that developers should produce module and integration level automatic tests. If they aren't automatic then they won't be performed. When a failure occurs, a test should be added to the list to make it fail, then and only then should it be fixed. Once fixed, the regression tests should be run and the failure should not occur.
2. Clean -- Code should be clean. This means easy to read, easy to parse, proper indenting, good variable names, etc..
3. Commented - Code should be well commented. I don't understand coders who do not write comments as they write the code. For complex functions I write the comments first and then fill in the code. For normal modules, I always have block comments as well as lines when I do something semi tricky. Anyone who expects to come back to properly comment code later is fooling themselves. Comments also are not only for other developers but for yourself as well. How many times have you stumbled across a section of your own code and wondered what you were smoking at the time?
4. Consistent/Coherent - Every coder has his/her own style. It is very difficult to standardize or mandate a certainly specific style within one engineering organization. Even with the different styles, the style should be consistent. If you but spaces around operators, then you should do so every time. Modules should be introduced the same way every time. Variable name choices should be consistent. Coherent is another word which has similar meaning.
5. Cohesive - Code should be written so it has an orderly, logical, aesthetically consistent relation of parts. It should fit well together and the places were it is divided into modules should make sense and survive the test of least astonishment to other developers.
6. Careful - Code must be written carefully. Whenever you allocate memory, you should immediately plan for its deallocation. When you write a structure allocation function, you should write the deallocation. When you open a file, you should close it right afterwards and then insert the operator code between the open and close. In general, code never gets reviewed or debugged enough before it goes into service. If you spent some extra time being careful and going over worse case, bad arguments, boundary conditions, and other scenarios in your mind while your write the code then your bugs per line and other problems should decrease.

Free Spam Protection   Android ORM   Simple Java Zip   JMX using HTTP   Great Eggnog Recipe