Showing posts from January, 2014

#4. Avoid fall-through in nonempty cases of "switch" statements

Each case label in a switch statement shall be followed by one of the following:
Any number of statements, followed by a break instruction.Another case label.A default label. Do not write statements below a case label and without a break instruction after them. It is confusing.

A switch statement is a controlled jump. Every time the code execution encounters the keyword switch, it will jump to a different place. The question is where. And the answer is:
To the case which is equal to the value of the expression in the switch, if there is one;To the default case, if there isn't one of the above and it exists;To the line after the closing bracket in the switch block, otherwise. In the first case, when the break instruction is reached, the execution flow will jump to the line after the closing bracket in the switch block.

Or should I say "if"? The break instruction is actually optional. You could omit it, and the execution flow would fall through to the instructions after the …

#3. The condition in an "if" statement should be a simple boolean expression with no side effects

The expression inside an if statement should be boolean, simple, and have no side effects.

In C++, every statement is an expression of a certain type. It may be an ordinary type, such as bool, int or a user-defined type such as Customer), or a special type called void which basically means "no type".

In C++ the expression inside the pair of brackets will be understood as a boolean expression. Some people carry the habit from their C days and pass an as int an argument to the if. Other people even use a pointer, so that the if will check whether it is NULL and will evaluate to truein that case. Don't do it - it makes the code less readable and a step closer to being error prone.
Guideline #2 advised you to avoid implicit type conversions. This is a very good place to start applying it. The if statement requires a bool, so why pass it anything else?
Don't overcomplicate things by putting several actions together. Don't use complex commands which may succeed or not,…

#2. Make all type conversions explicit

Assignments, function calls and expressions in general should not contain implicit type conversions. All type conversions should be explicit.

Type conversions should be isolated in their own line, which should consist only of the assignment of the result of the type conversion to a variable of the target type.

A statement should not mix type conversion with other operations. For example, if you need to convert an object to one of another type to pass it as a function parameter, do not do it in the function call itself; instead, do it in a separate instruction in the previous line.
Type conversion occurs when an entity of type A is, well, converted to an entity of type B. This may occur in function calls, expressions using operators, or assignments.
An explicit type conversion is one which you can read in the code. An implicit type conversion is one which does not appear in the source code, but is done automatically when the software is executed.
Making all type conversions explicit he…

#1. Do one thing at a time

Do exactly one thing in each instruction, and put each of them in a separate line of code. This will enhance the readability of your code and make it easier to debug and possibly change in the future.

It should not be possible for an instruction to have several potential causes of failure.

If an instruction is a function call, its arguments should be trivial expressions. If its purpose is to get some result, don’t do anything complicated with it once you get it; instead, place the result in a variable and do subsequent operations with it in the following lines.

If you write code in this way you will find out that it follows your train of thought quite closely. For this reason, a future reader (whether it is another programmer or you) will have a better chance of understanding it.
Bibliography[McConnell 2004] Steve McConnell: Code Complete, 2nd Edition, Microsoft Press, 2004.
Chapter 31: "Layout and Style". Section 31.5: "Laying out individual statements" and its S…