By placing the public section first, everything that is of interest
to a user is gathered in the beginning of the class definition. The
protected section may be of interest to designers when considering
inheriting from the class. The private section contains details that
should have the least general interest.

A member function that is defined within a class definition
automatically becomes inline. Class definitions are less compact and more
difficult to read when they include definitions of member functions. It
is easier for an inline member function to become an ordinary member
function if the definition of the inline function is placed outside of
the class definition. This rule will be in effect at least as long as
traditional text editors are used.

A similar problem is that members are private if no access
specifier is explicitly given. This problem is avoided by following
Rule 20.

When declaring functions, the
leading parenthesis and the first argument (if any) are to be written
on the same line as the function name. If space permits, other
arguments and the closing parenthesis may also be written on the same
line as the function name. Otherwise, each additional argument is to be
written on a separate line (with the closing parenthesis directly after
the last argument).

If no return type is explicitly provided for a function, it is, by
default, an int. It is recommended to always provide the return type
explicitly, to increase the readability of the code. By defining the
return type on a separate line directly above the function definition,
the function name is more easily seen.

The other recommendations are meant to give a uniform appearance
to the code that is written. Until such time as formatting tools are
available, programmers should follow these guidelines.

Braces ("{}") which enclose a block
are to be placed in the same column, on separate lines directly before
and after the block.

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 which, in our opinion, gives the most readable code. Other
styles may well provide more compact code.

The flow control primitives
if, else, while, for
and do should be followed by a block, even if it
is an empty block.

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.

The dereference 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 that they are part of the type
definition. Instead of saying that *i is an int,
say that i is an int*.

Traditionally, C recommendations indicate that `*'
should be written together with the variable name, since 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, however,
such a advice is unneeded.

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

Ordinary spaces should be used instead of tabs. Since different editors
treat tab characters differently, the work in perfecting a layout may
have been wasted if another editor is later used. Tab characters can be
removed using the UNIX command expand. One alternative is
to format code using the editor GNU Emacs.

We recommend that everyone use GNU Emacs to format code. Code will
then have a uniform appearance regardless of who has written it.