Skip to main content

Good Style of Programming

Here are few tips to program your C / C++ code in good style :


Using break is ok in loops. Ideally, the loop should be structured to iterate in the most straightforward way. The break in the body can detect the exceptional case that comes up during the iteration.

for (i = 0; i < length; i++ )
    if (<found>) break;


while (current != NULL)
    if (<found>) break;


while (TRUE) types loops are fine if they are really necessary. Often you need this for the loop-and-a-half-type situation where you need to first do some processing before you are able to test whether you need to exit the loop. If the first statement of a while (TRUE) loop is the test, then you should just put the test directly into the while statement. If the bounds of iteration are known, then a for loop is preferable.


A return in a place other than the end of a function body is potentially vulgar. The early return can be used nicely if it detects and immediately exits on an exceptional case-for example, a recursive base case or an error case right at the beginning of a function. Sometimes return can be used like a break inside a loop when some condition becomes true. Be careful with return in the bodies of your functions- experience shows they are responsible for a disproportionate number of bugs. The programmer forgets about the early-return case and assumes the function runs all the way to its end.

Increment Operators ++, –

Nice obvious uses of these are fine, but nesting it inside something complicated is just asking for trouble. Find a more useful outlet for your cleverness.

for (i = 0; i < length; i++) … // Ok
while (–length) … // Ok
while (*t++ = *s++) … // Sick


If you ever exploit the fall-through property of cases within a switch, your documentation should definitely say so. It’s pretty unusual. !=, ==

This is just a minor readability issue, but it’s nice to put in what you are really testing for, rather than rely on the anything-non-zero-is-true property. Even though the code may compile to exactly the same thing, it reads a little nicer.

if (*current) more clearly is if (*current != ”)
if (current) more clearly is if (current != NULL)
if (!count) more clearly is if (count == 0)

Boolean Values

Boolean expressions and variables seem to be prone to redundancy and awkwardness. Replace repetitive constructions with the more concise and direct alternatives. If you have a boolean value, don’t use additional != or == operators on it to test its value. Just use its value directly or inverted. Also, watch for if-else statements that assign a variable to true or false. The result from evaluating the test can go right into the variable. A few examples :

if (flag == TRUE) more succinctly is if (flag)
if (matches > 0) more succinctly is found = (matches > 0);
found = TRUE;
found = FALSE;
if (hadError == FALSE) more succinctly is return !hadError;
return TRUE;
return FALSE;


#define-d constants should be independent; that is, you should only need to change one #define to change something about a program. For example :

#define RectWidth 3
#define RectHeight 2 /* WARNING: problem */
#define RectPerimeter 10

is not so hot, because if you wanted to change RectWidth or RectHeight, you would also have to remember to change RectPerimeter. A better way is :

#define RectWidth 3
#define RectHeight 2
#define RectPerimeter (2*RectWidth + 2*RectHeight)


Popular posts from this blog

Exploring Node.js Internals

I found a great article explaining Node JS internals, must read : Some other articles : Introduction to Node.js Being an official website, explains what Node.js is, as well as its package managers, and lists web frameworks built on top of it. “ JavaScript & Node.js ”,  The Node Beginner Book This book by  Manuel Kiessling  does a fantastic job of explaining Node.js, after warning that JavaScript in the browser is not the same as the one in Node.js, even though both are written in the same language. Beginning Node.js This beginner book goes beyond an explanation of the runtime. It teaches about packages and streams and creating a web server with the Express framework. LibUV This is the official documentation of the supporting C++ code of the Node.js runtime. V8 This is the official documentation of the JavaScript engine that makes it possible to write Node.js with JavaScript.

Hibernate Object Conversations

Session methods to use for object conversations Save() A new instance being attached to the session. An insert will be scheduled. Update() Call Update to make a transient object persistent again. It will force a SQL update on the transient object. This is because Hibernate does not know whether the object is dirty or not and to be safe by default schedules an update. This method will throw an exception, if the entity is already registered with the session. - NonUniqueObjectException is thrown. saveOrUpdate() Either a save or an update will be called based on whether the identifier exists or not. No identifier - save is called, else update is called. Or for a better understanding, if the object is transient, then a save is called, if the object is persistent, then an update is called. Reattaching an unmodified instance - If you know for sure that an object is not modified and you just want to make it persistent again - Session.lock(item, LockMode.No