Sunday, March 16, 2008

Coding better C++

I've prepared a short guideline for writing better codes in C++. I've prepared the list from my C++ experiences and studies. Each item of the list needs good amount of explanation which is outside of the scope of this post. I'll try to explain them in the future posts in my blog. For now, if you need more information on an suggested item, you can look up on the internet or in the books.

Here it goes:
  1. C++ is not C. Stop mixing C and C++ unless it is required. Start thinking in C++.
  2. Have a C++ coding standard defined or follow the coding standard defined for your project or organization.
  3. Design from outside, design the interfaces first.
  4. Avoid using assignments in constructors, use initializer list to initialize members.
  5. Know the need of copy constructor and define when needed.
  6. Use virtual destructor when your class is used as a base class.
  7. Never call a destructor (unless you're using a placement new). If you do, you may need to revise your software design.
  8. Avoid using placement new.
  9. Avoid using Macros for functions. Use Inline functions instead.
  10. Avoid using Array, unless you have to. Use standard library containers like Vector, etc.
  11. Avoid C style cast, use the C++ casts.
  12. Use references when you can and pointers when you have to.
  13. Use composition when you can and private inheritance when you have to.
  14. Use const for function parameters when you can.
  15. Be careful about static initializations, you might get unexpected behavior if the static variables/objects has dependencies.
  16. Be careful about multiple inheritance. Understand the 'dreaded diamond'.
  17. Be careful about floats and doubles. They may give you unexpected behaviors.
  18. Avoid constant literals in the code. Separate them in static inline functions or macros.
Each suggestion, mentioned above, will take time to get used to (if you're not already). For example, item 1 says "C++ is not C. Stop mixing C and C++ unless it is required. Start thinking in C++.". Now if you were a C programmer, it is not easy to stop using C, for example: it may become difficult for you to stop using stdio functions and using iostream instead. It'll take time and practice. (Please note, stdio functions might have advantages over iostream but that's not the point here).

Once you get used to all of the suggested points, you'll find that your code is much much better than many others and of course, more optimized and less error prone. Let me emphasize, 'these are golden suggestions, try to follow them'.

Happy coding :).


Z said...

I agree to most of your points actually. Though I still couldn't elevate myself from using stdio and old C functions in C++. I still use them like hell and so far haven't encountered any major problem but your suggestion is certainly the way to go, and I think people should really use the STD C++ libs more than the older C libs.

I didn't understand why using initializers maybe better than using assignments.

Secondly, for extreme optimizations, sometimes you have to break the golden rules.At times there are no ways other than to write very ugly looking codes just for the sake of optimization. It depends actually and I believe a smart programmer knows when to balance between golden rules and ugly codes :).

But I agree to all your suggestions when extreme optimization is not a big concern.


luc said...

Great article. It's a great thing to able to express and share the knowledge gained through out the years. I congratulate you on your effort of sharing valuable experience of Software Programming/Development through your blogs and articles. I think it will assist a great deal to aspiring programmars and developers.

think your point about Private Inheritance (point 13) is something not very familiar to me and some of my colleagues. I haven't seen people use private inheritance to a good effect in any samples or any projects I came across.
In Java, are you able to do something like Private Inheritance?
I think this point needs a little more explanation from you.

M. Kaisar Ul Haque said...

I apologize for this late reply to your comments.


With stdio functions you can sometimes simplify your works and sometimes may gain performance. But in many cases, none of them might be true. Mixing stdio with iostream may complicate/mess your code, may produce larger executables and may prevent you from doing proper object oriented coding. For example. you cannot do the following with stdio, that we can with iostream (using operator overloading):

MyClass object;

cout << object;

I've explained why to avoid using assignments in the constructors, in my next post, here:


Thanks for your nice words!

I shall post a detailed discussion on "13.Use composition when you can and private inheritance when you have to" soon.


hakeliha said...

I disagree on having to make ugly code ever. Optimization is not about hacks, it's about algorithms and knowing the inner works of your libraries.

Coding is three-way communication where the programmer himself, computer and any third programmer must be able to understand what the code is supposed to do. Keep it clean.