Most crucial elements in a light-weight C++ coding standard [closed]

Answer 1

Make sure that your compiler's warning level is set high enough (/Wall preferably) so that it will catch silly mistakes like:

if (p = 0)

when you really meant

if (p == 0)

so that you don't need to resort to even sillier tricks like:

if (0 == p)

which degrade the readability of your code.

Answer 2

Forbid t[i]=i++; f(i++,i);, and so on as there is no (portable) guarantees regarding what is executed first.

Answer 3

Avoid using generated copy constructor and operator= by default.

• If you want your object to be copiable.
  • If every attribute can be trivially copied, comment clearly you are using implicit copy constructor and operator= deliberately.
  • Otherwise, write your own constructors, using the initialization field to initialize attributes and following the header order (which is the real construction order).
• If still don't know (default option) or you think you dont want to copy the objects of a certain class, declare its copy constructor and operator= as private. This way the compiler will let you know when you are doing something you don't want to do.

    class foo
    {
       //...
    private:
       foo( const foo& );
       const foo& operator=( const foo& );
    };

Or in a cleaner way if you are using boost:

    class foo : private boost::noncopyable
    {
      ...
    };

Answer 4

Use C++ casts instead of C casts

use:

• static_cast
• const_cast
• reinterpret_cast
• dynamic_cast

but never C-style casts.

How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.

Each cast has limited powers. E.g., if you want to remove a const (for whatever reason), const_cast won't change the type at the same time (which could be a bug difficult to find).

Also, this enables a reviewer to search for them and then, the coder to justify them if needed.

Answer 5

Use references instead of pointers where possible. This prevents constant defensive NULL checks.

Answer 6

Premature optimization is the root of all evil

Write safe and correct code first.

Then, if you have performance problems, and if your profiler told you the code is slow, you can try to optimize it.

Never believe you will optimize snippets of code better than the compiler.

When looking for optimizations, study the algorithms used, and potentially better alternatives.

How it clearly facilitates safer code, which minimizes the risk of enigmatic bugs, which increases maintainability, etc.?

Usually, "optimized" (or supposedly optimized) code is a lot less clearer, and tend to express itself through raw, near-the-machine way, instead of a more business-oriented way. Some optimizations rely of switchs, if, etc., and then will be more difficult to test because of multiple code paths.

And of course, optimization before profiling often lead to zero performance gain.