21. Summary of Recommendations
- Rec. 1
- Optimize code only if you know that
you have a performance problem. Think twice before you begin.
- Rec. 2
- If you use a C++ compiler that is based
on Cfront, always compile with the
+w
flag set to eliminate as many warnings as possible.
- Rec. 3
- An include file should not contain more
than one class definition.
- Rec. 4
- Divide up the definitions of member
functions or functions into as many files as possible.
- Rec. 5
- Place machine-dependent code in a special
file so that it may be easily located when porting code from one machine to another.
- Rec. 6
- Always give a file a name that is unique
in as large a context as possible.
- Rec. 7
- An include file for a class should have
a file name of the form <class name> + extension. Use uppercase and lowercase
letters in the same way as in the source code.
- Rec. 8
- Write some descriptive comments before
every function.
- Rec. 9
- Use
//
for comments.
- Rec. 10
- Use the directive
#include "filename.hh"
for user-prepared include files.
- Rec. 11
- Use the directive
#include <filename.hh>
for include files from libraries.
- Rec. 12
- Every implementation file should declare
a local constant string that describes the file so the UNIX command
what
can be used to obtain information on the file revision.
- Rec. 13
- Never include other files in an `.icc'
file.
- Rec. 14
- Do not use typenames that differ only
by the use of uppercase and lowercase letters.
- Rec. 15
- Names should not include abbreviations
that are not generally accepted.
- Rec. 16
- A variable with a large scope should
have a long name.
- Rec. 17
- Choose variable names that suggest
the usage.
- Rec. 18
- Write code in a way that makes it
easy to change the prefix for global identifiers.
- Rec. 19
- Encapsulate global variables and constants,
enumerated types, and typedefs in a class.
- Rec. 20
- Always provide the return type
of a function explicitly.
- Rec. 21
- 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).
- Rec. 22
- In a function definition, the return
type
of the function should be written on a separate line directly above the function
name.
- Rec. 23
- Always write the left parenthesis
directly after a function name.
- Rec. 24
- Braces (`
{}') which enclose
a block are to be placed in the same column, on separate lines directly before and
after the block.
- Rec. 25
- The flow control primitives
if,
else, while, for and do
should be followed by a block, even if it is an empty block.
- Rec. 26
- The dereference operator `
*'
and the address-of operator `&' should be directly connected
with the type names in declarations and definitions.
- Rec. 27
- Do not use spaces around `
.'
or `->', nor between unary operators and operands.
- Rec. 28
- Use the c++ mode in GNU Emacs to format
code.
- Rec. 29
- Access functions are to be inline.
- Rec. 30
- Forwarding functions are to be inline.
- Rec. 31
- Constructors and destructors must
not be inline.
- Rec. 32
- Friends of a class should be used
to provide additional functions that are best kept outside of the class.
- Rec. 33
- Avoid the use of global objects in
constructors and destructors.
- Rec. 34
- An assignment operator ought to return
a const
reference to the assigning object.
- Rec. 35
- Use operator overloading sparingly
and in a uniform manner.
- Rec. 36
- When two operators are opposites (such
as
== and !=), it is appropriate to define both.
- Rec. 37
- Avoid inheritance for parts-of relations.
- Rec. 38
- Give derived classes access to class
type member data by declaring protected access functions.
- Rec. 39
- Do not attempt to create an instance
of a class template using a type that does not define the member functions which
the class template, according to its documentation, requires.
- Rec. 40
- Take care to avoid multiple definition
of overloaded functions in conjunction with the instantiation of a class template.
- Rec. 41
- Avoid functions with many arguments.
- Rec. 42
- If a function stores a pointer to
an object which is accessed via an argument, let the argument have the type pointer.
Use reference arguments in other cases.
- Rec. 43
- Use constant references (
const &)
instead of call-by-value, unless using a pre-defined data type or a pointer.
- Rec. 44
- When overloading functions, all variations
should have the same semantics (be used for the same purpose).
- Rec. 45
- Use
inline
functions when they are really needed.
- Rec. 46
- Minimize the number of temporary objects
that are created as return values from functions or as arguments to functions.
- Rec. 47
- Avoid long and complex functions.
- Rec. 48
- Pointers to pointers should whenever
possible be avoided.
- Rec. 49
- Use a
typedef
to simplify program syntax when declaring function pointers.
- Rec. 50
- The choice of loop construct (
for,
while or do-while) should depend on the
specific use of the loop.
- Rec. 51
- Always use
unsigned
for variables which cannot reasonably have negative values.
- Rec. 52
- Always use inclusive lower limits
and exclusive upper limits.
- Rec. 53
- Avoid the use of
continue.
- Rec. 54
- Use
break
to exit a loop if this avoids the use of flags.
- Rec. 55
- Do not write logical expressions of the
type
if(test) or if(!test)
when
test
is a pointer.
- Rec. 56
- Use parentheses to clarify the order
of evaluation for operators in expressions.
- Rec. 57
- Avoid global data if at all possible.
- Rec. 58
- Do not allocate memory and expect
that someone else will deallocate it later.
- Rec. 59
- Always assign a new value to a pointer
that points to deallocated memory.
- Rec. 60
- Make sure that fault handling is
done so that the transfer to exception handling (when this is available in C++)
may be easily made.
- Rec. 61
- Check the fault codes which may be
received from library functions even if these functions seem foolproof.