46 advices, tools and best practices from the book C++ Coding Standards
-
Think. Do follow good guidelines conscientiously; but don’t follow them blindly. No set of guidelines, however good, should try to be a substitute for thinking.
-
Manage pressure. As software developers, we routinely face enormous pressure to deliver tomorrow’s software yesterday. Under schedule pressure, we do what we are trained to do and are used to doing.
-
Coding Style.
- Don’t specify how much to indent, but do indent to show structure.
- Don’t enforce a specific line length, but do keep line lengths readable.
- Don’t overlegislate naming, but do use a consistent naming convention.
- Write useful comments. Write code instead of comments where possible.
- Don’t just place braces randomly or in a way that obscures scope nesting.
- Try to follow the style already in use in each file.
-
Take warnings to heart.
- Use your computer’s highest warning level.
- Require clean and warning-free builds.
- Understand all warnings.
- Eliminate warnings by changing your code, not by reducing the warning level.
-
One-action build system. Push one button. Use a fully automatic one-action build system that builds the whole project without user intervention.
-
Successful builds produce no noise. The ideal build is silent and warning-free and produce only one log message: Build succeeded.
-
Version Control System (VCS). The palest of ink is better than the best memory (Chinese proverb).
-
Don’t break the build. The code in the VCS must always build successfully.
-
Re-view code. More eyes will help make more quality. Show your code, and read others’. You’ll all learn and benefit.
-
What come first. Correctness, simplicity, and clarity come first.
-
Focus on one thing at a time. Prefer to give each entity (variable, class, function, namespace, module, library) one well-defined responsibility.
-
Keep Entity’s responsibilities limited. As an entity grows, its scope of responsibility naturally increases, but its responsibility should not diverge.
-
One sentence is enough. A good business idea, they say, can be explained in one sentence.
-
better than.
- Correct is better than fast.
- Simple is better than complex.
- Clear is better than cute.
- Safe is better than insecure.
-
KISS. Keep It Simple Software. What you can’t comprehend, you can’t change with confidence.
-
Manage more data. Whatever your code does today it may be asked to do tomorrow against much more data.
-
Choose flexibile and dynamic data structures. Use flexible, dynamically allocated data structures instead of fixed-size. Arrays larger than the largest I’ll ever need are a terrible correctness and security fallacy.
-
Prefer to use linear (or better) algorithms wherever possible. Avoid polynomial algorithms where reasonable.
-
Exponential algorithms. Avoid them with all your might.
-
The first rule of optimization. Don’t do it
-
The second rule of optimization (for experts only): Don’t do it yet.
-
Optimization goals. Measure twice, optimize once. Optimization must be preceded by measurement; and measurement must be preceded by optimization goals. Until the need is proven, your focus should be on priority.
-
Demand proof. When someone asks you to optimize, do demand proof.
-
Easy on yourself. Easy on the code.
-
Sharing causes contention. Avoid shared data, especially global data. Shared data increases coupling, which reduces maintainability and often performance.
-
Share nothing. Prefer communication (e.g., message queues) over data sharing.
-
Information hiding. Don’t tell. Don’t expose. Use abstraction.
-
One man’s constant is another man’s variable. The C++ Standard says not one word about threads. Nevertheless, C++ is routinely and widely used to write solid multithreaded code.
-
Compile-time polymorphism. Consider replacing run-time polymorphism (virtual functions) with compile-time polymorphism (templates) when defining generic functions or type.
-
Const is viral. Add it in one place, and it wants to propagate throughout your code as you call other functions whose signatures aren’t yet const-correct.
-
Const-correctness is worthwhile. It is proven, effective, and highly recommended.
-
The first rule about macros. Don’t use them.
-
The second rule about macros. Don’t use them unless you have to.
-
Are macros good?. Almost every macro demonstrates a flaw in the programming language, in the program, or in the programmer.
-
Are macros always bad?. Macros remain the only solution for a few important tasks, such as #include guards, #ifdef and #if defined for conditional compilation, and implementing assert.
-
No magician required.Programming isn’t magic, so don’t incant it.
-
State make you vulnerable. Variables introduce state, and you should have to deal with as little state as possible, with lifetimes as short as possible.
-
Sensible initialization. Don’t declare a variable before you can initialize it sensibly.
-
Memory management requires disciplines. Clean memory before you use it. Initialize variables upon definition.
-
Wisdom means knowing when to refrain. Write to minimize duplication and maximize efficiency. But premature optimization is dangerous.
-
Clarity. Above all. The most important single aspect of software development is to be clear about what you are trying to build - Bjarne Stroustrup.
-
Avoid inheritance taxes. Prefer composition to inheritance unless you know that the latter truly benefits your design.
-
Prefer weakest relationship instead of strongest. If a relationship can be expressed in more than one way, use the weakest relationship that’s practical.
-
Composition wins inheritance.
- Greater flexibility without affecting calling code
- Greater compile-time insulation, shorter compile times
-
Don’t pay for what you don’t need. Unless you need inheritance’s power, don’t endure its drawbacks.
-
Behavior and state. Prefer to add non member functions instead of member functions. Prefer composition instead of inheritance
##Further Information C++ Coding Standards: 101 Rules, Guidelines, And Best Practices, by Herb Sutter, Andrei Alexandrescu, Bjarne Stroustrup