Recommended coding practices in C++

This page is meant for students working with us on projects and writing code in C++. The guidelines are far from exhaustive. While some guidelines are common sense C++ programming tips, some others on this page are purely personal preferences.

Why C when you can C++?
  • If you can write a program in C++, prefer it to C.
  • Programming is even more about debugging, testing, and refactoring.
  • C++ offers a lot of advantages over C and should be an obvious choice, particularly in the light of the previous statement.

Keep it simple silly…
  • Programming has a lot to do with debugging and refactoring. So a well written program should be such that it is easy to debug, and easy to understand, so that it can be refactored whenever needed, by anyone, including yourself 🙂
  • A piece of code can be complex (to understand) only if it offers greater speed in return. But remember, greater speed is needed only in time critical inner loops, not in functions that are called only a couple of times in the whole run.
  • A key to simplicity is understanding the fact that each function your write offers an opportunity to delegate understanding. So try writing programs in such a way that they heirarchially delegate understanding from coarser levels to finer levels.

Programming choices
  • Make each of the functions small, digestible, tasty morsels of code.
  • If one such tasty morsel is called too often in an inner loop, make it an inline function.
  • As far as possible, limit the scope of variables. For instance, if a variable required inside a loop, is reassigned on each iteration, declare it inside the loop.
  • Avoid global variables. Fewer global variables make everyone’s life easier.
  • The idea behind using classes is that they encapsulate data and functions. Said otherwise, each instance of a class holds a certain state, that is stored in the data. So make those variables of code class members, that hold the state in a program. Others can be made local. Though, any number of member variables can be used, they are still global in nature; I still prefer passing variables across function as arguments, to clearly understand which function changes which variable and when.

Comments in code
  • Be generous with comments your code. I can not emphasize this enough. If you are like, me you will realize how quickly your forget how and why you have written some code. Comments are indispensible for anyone who wants to read your code. Personally, it works better than documentation for me. In addition if you make them doxygen compatible (one way is to just type /// in front of comments that you think should be part of your documentation), you can even have ‘real’ documentation for free.

Code-wise…
  • Avoid goto statements. Usual advice in most C++ programming books. There is always another way to write the program if you have used them.
  • Use the reference operator, &, to pass arguments, avoid using pointers for this purpose.
  • If an argument that is passed to a function does not change within the scope of the function, pass it as a const value. Such little details make it easier to understand code, apart from making it less error-prone
  • Use STL (standard template library) vector class instead of dynamically allocated arrays wherever possible. They are easy to use, are as fast as arrays, can be dynamically allocated, and yet do not need to be deleted after use.
  • Avoid using ?: operators, use if-else instead. Oh by the way, I hear it is faster in execution too besides being easier to understand.
  • Use CamelBack notation to name variables, function and classes. Start the names of variables with small letters and those of classes and function with capitals.
  • Use nice, understandable, short, but descriptive names for variables, functions and classes
  • In general, things seem nice if one uses nouns for names of classes and verbs for names of functions.
  • Note the code below. Try using the same order of spaces as the code below. Start the curly braces on the next line after the for statement, and close them promptly after the last line.

  • for( int x = 0; x < 100; x++ )
    {

    ……..
    ……..

    }

  • Do not be shy to rewrite one line code of the following form:
  • int x = 100;
    if( somethingIsTrue ) while( x > 0 ) {x–;y++;z++;}

    as:

    int x = 100;
    if( somethingIsTrue )
    {

    while( x > 0 )
    {

    x–;
    y++;
    z++;

    }

    }

  • When in doubt about operator precedence, or even otherwise for easier reading, use parenthesis in mathematical expressions.
  • The statement if( 10 == x ){…} is better than if( x == 10 ){…} because it prevents the common coding error where if( x == 10) can be written as if( x = 10 ), which assigns x with 10 (and returns true) rather than checking if its value is 10.
  • Use m_memberVariableName for member variables, and g_memberVariableName, if you do end up using global variables

Code self checking
  • Use plenty of _ASSERT( value == shouldbethis ) statements in code. Such statements verify the values as expected in say, inner loops where one does not want to be checking values manually.

Of course, every suggestion here can be ignored. My emphasis is mainly on producing code that is more readable, and that helps delegate understanding better. What is presented on this page is some of what I learnt from my line manager at

muvee Technologies

, Gerry Beauregard.

Good programming requires balanced thinking; one has to design the finer details of the program keeping in view all the time how they fit into the larger picture, the complete system. Perhaps I can argue that a good programmer has a very practical approach to things in his life. He is able to weigh tradeoffs in life with respect to short term and long term gains. He is able to face facts, and break them down into coherent, simple parts, and have an honest approach in everything he does.

From whatever I have seen of C++, I like it. Yeah, they say C++ is not perfect. But in the words of Bjarne Stroustroup himself: “There are programming languages people complain about all the time, and there are those that are never used”. If there are mistakes on this page, or if there are more points you would like to see added, please let me (radhakrishna [dot] achanta [at] epfl [dot] ch) know. I would be glad to improve this page.