Here it goes:
- C++ is not C. Stop mixing C and C++ unless it is required. Start thinking in C++.
- Have a C++ coding standard defined or follow the coding standard defined for your project or organization.
- Design from outside, design the interfaces first.
- Avoid using assignments in constructors, use initializer list to initialize members.
- Know the need of copy constructor and define when needed.
- Use virtual destructor when your class is used as a base class.
- Never call a destructor (unless you're using a placement new). If you do, you may need to revise your software design.
- Avoid using placement new.
- Avoid using Macros for functions. Use Inline functions instead.
- Avoid using Array, unless you have to. Use standard library containers like Vector, etc.
- Avoid C style cast, use the C++ casts.
- Use references when you can and pointers when you have to.
- Use composition when you can and private inheritance when you have to.
- Use const for function parameters when you can.
- Be careful about static initializations, you might get unexpected behavior if the static variables/objects has dependencies.
- Be careful about multiple inheritance. Understand the 'dreaded diamond'.
- Be careful about floats and doubles. They may give you unexpected behaviors.
- Avoid constant literals in the code. Separate them in static inline functions or macros.
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 :).
4 comments:
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.
Z.
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.
I apologize for this late reply to your comments.
@Z:
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:
http://kaisar-haque.blogspot.com/2008/06/c-avoid-using-assignments-in.html
@luc:
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.
Thanks!
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.
Post a Comment