Compound Statements

Rule 34.Braces ({}) that enclose a block must be placed in the same column, on separate lines directly before and after the block.

Exception:Braces may be placed on the same line if they enclose an empty function or operator body.

The placement of braces seems to have been the subject of the greatest debate concerning the appearance of both C and C++ code. We recommend the style that, in our opinion, gives the most readable code. Other styles may well provide code that is more compact.

Flow Control Statements

Rule 35.The flow control primitivesif,else,while,for, anddomust be followed by a block enclosed in the braces ({}), even if it is an empty block. Do not place an empty block after theifandelseoperators.

Exception:If a flow control primitive executable statement occupies only one line and it is not empty, the block braces may be omitted.

Rule 36.Always place a space between aswitch,if,for,while,do, andcatchstatement and the leading parenthesis of its expression.

At times, everything that is to be done in a loop may be easily written on one line in the loop statement itself. It may then be tempting to conclude the statement with a semicolon at the end of the line. This may lead to misunderstanding since, when reading the code, it is easy to miss such a semicolon. It seems to be better, in such cases, to place an empty block after the statement to make completely clear what the code is doing. See Example 20.

Placing a space between a switch,if,for,while,do, andcatchstatement, you distinguish those statements from functions to make code more readable.

Pointers and References

Rule 37.The de-reference operator*and the address-of operator&should be directly connected with the type names in declarations and definitions.

The characters *and&should be written together with the types of variables instead of with the names of variables in order to emphasize they are part of the type definition. Instead of saying that*iis anint, say thatiis anint*. SeeExample 21.

Traditionally, C recommendations indicate that *should be written together with the variable name. This reduces the probability of making a mistake when declaring several variables in the same declaration statement (the operator*only applies to the variable on which it operates). Since the declaration of several variables in the same statement is not recommended, such an advice is unneeded. SeeExample 22.

Miscellaneous

Rule 38.Do not use spaces between the following operators, operands, and their expressions: scope resolution operator::; array element operator[]; function call operator(); type-cast operator(type); structure, union, and class member operators.and->; postfix and prefix increment and decrement operators++,--; indirection operator*; address-of operator&; logical-NOT operator!; one’s complement operator~; pointer to member operators.*and->*.

Rule 39.Always place spaces between operands and expressions of the following operators: multiplication operator*; division operator/; modulus operator%; addition operator+; subtraction operator-; bitwise left shift and right shift operators<<,>>; relational and equality operators<,<=,>,>=,==,!=; bitwise-AND operator&; bitwise-exclusive-OR operator^; bitwise-inclusive-OR operator|; logical-AND operator&&; logical-OR operator||; assignment operators=,+=,-=,*=,/=,%=,>>=,<<=,&=,^=,|=; conditional operator?:;

Rule 40. Never place spaces between the leading and closing parentheses(), square brackets[], angle brackets<>and their enclosed statement(s).

Rule 41.Never place a space between a statement and its closing;or,.

Rule 42.Do not place two different statements ending by;on the same line unless it is an expression of a flow control primitive.

Rule 43.If statements are written on the same line, they must be separated by spaces.

Rule 44.Statements within a block should be indented by one tab. Do not use blank spaces to indent statements within a block. Never use tabs in other places. Use blanks instead.

In our opinion, code is more readable if spaces are not used around the .or->operators. The same applies to unary operators (operating on one operand), since a space may give the impression that the unary operand is actually a binary operator. On the contrary, use spaces to mark the operands of binary operators.

When two statements are written on the same line, code becomes less readable. See Example 23.

It is a good practice to make code more readable by indenting statements within a block. By indenting statements within a block by a tab, you make it possible to use a different indentation level later. On the other hand, different editors treat tab characters differently, so the work in perfecting a layout may have been wasted if another editor is later used. Ordinary spaces should be used instead of tabs within statements to avoid it.