Ellemtel C++ Styel and Rules - 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.