A member function shall never return a reference or a pointer to a local variable. This will result in a pointer referencing a variable that has gone out of scope when the function returns.

A member function that does not modify member data shall be declared const.

A public member function shall never return a non-const reference or pointer to member data.

A public member function shall never return a non-const reference or pointer to data outside an object, unless the object shares the data with other objects.

No member functions shall be implemented within the class header declaration. The only exceptions are accessors and mutators (gets and sets).

If the behavior of an object is dependent on data outside the object, this data shall not to be modified by const member functions.

Avoid overloading on a pointer type.

An assignment operator shall return a reference to the assigning object (as the assignment operator returns the left hand side (LHS)). Non-const reference is consistent with the behavior of built-in types.

When overloading the assignment operator, assignment to self shall be checked by adding the check at the beginning of the assignment method.

Inheritance shall not be used for parts-of relations. Use template classes for parts-of relations.

Use inheritance to implement a generalization to specialization (kind of) relationships.

Inherited non-virtual member functions shall not be overridden.

Uninitialized data present in variables, objects, etc. have led to many problems. Often the problems manifest themselves as the very difficult "unable to reproduce" kind of problem at test time since the behavior of programs is dependent on the content of unitialized variables, which may or may not change with every execution.

The section cites standards for File Size and Structure.

While such names may be permitted by C++ standard and supported by compilers, names that very solely by case tend to create readability problems for the maintenance programmer.

Indent the continued part of a statement at least one indentation level beyond the start of the statement.

Indentation shall be performed using spaces instead of tab characters.

Indentation shall be consistent throughout all source files.

The '*' and '&' shall be directly connected with the type names in declarations and definitions. I.e., no space shall be placed between the '*' or '&' and the type names in declarations and definitions.

There shall be no spaces between a function name and the left parentheses.

Begin each statement on a separate line.

Limit the length of source statements so that complete source statements is visible on the screen without having to scroll right and left repeatedly.

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

Each header file shall #include any other headers on which it directly depends.

#includes shall precede any declarations or definitions in a file.

#include shall not be used to insert executable code into a file or to insert part of a class definition from an external file unless it is required by the use of software developed externally to the project, such as commercial off-the-shelf (COTS) products.

Place #include statements in the following order:

Function prototypes and external variables shall be declared in a header file (to avoid multiple declarations), not in implementation files.

The return type of a function shall always be stated explicitly. Functions that do not return a value shall be declared as void.

Pass parameters in input, modify, output order.

Variable argument lists shall not be used (ellipses notation).

Where the return value from functions are stored for future use, the function invocation shall not be embedded in conditional or other function invocations. Functions may be embedded if return value is only used within that source.

Check the fault codes that may be received from library functions even if these functions seem fool proof.

Do not depend on the order of evaluation of arguments to a function.

Always return a value from main().

For functions with non-void return type, ensure that all paths have a return statement that contains an expression of the return type.

Calling functions shall check for errors reported from functions

Do not throw exceptions from within destructors.

Throw only objects of class type.

Avoid memory leaks in exception handling code by using references in parameter lists for exception handlers.

Pointer arithmetic shall not be used.

Do not depend on the behavior of underflow or overflow.

Apply unary minus to operands of signed type only.

Code shall not depend on implicit type conversions.

The following assignments shall not be used:

Do not convert floating values to integral types except through use of standard library routines.

A pointer shall not be compared to NULL or assigned NULL without casting the NULL to the proper type.

Do not allocate dynamic objects contained within other objects as instance data.

Class authors shall provide default values for dynamic objects within other objects and/or constructors that can be used on initializer lists.

Save the address of allocated memory to prevent orphaned allocation.

Explicitly deallocate a dynamically allocated segment prior to assigning a new value.

Avoid memory leaks in exception handling code.

Do not use code that can throw an exception in a destructor.

Avoid memory leaks involving external components.

Avoid memory leaks involving reuse of "dead" objects.

Avoid memory leaks by explicitly clearing memory after use.

Avoid memory leaks by unfreezing frozen stream objects.

Avoid memory leaks by ensuring that you write the operator delete whenever the operator new has been written for a class.

The size of an array shall be declared with an enum constant or const. This makes modifying the size of an array easier, and is more meaningful to the reader.

When reading array contents, check to ensure that the index does not exceed the array size.

When adding to an array, check to ensure that the size of the array can hold the existing content in addition to the new contents to be added.

Always test a pointer’s value for NULL before using it.

Java Software uses the following file suffixes:

Frequently used file names include:

A file consists of sections, separated by blank lines and an optional comment identifying each section

Avoid files longer than 2000 lines, since they are cumbersome.

Each Java source file contains a single public class or interface.

When private classes and interfaces are associated with a public class, put them in the same source file as the public class.

Make the public class the first class or interface in the file.

Order Java source files as follows:

Lines should be broken/ wrapped at column 100 for readability.

Lines longer than 80 characters, while allowed, may affect readability since they are not handled by many terminals and tools.

Examples for use in documentation should have no more than 70 characters.

When an expression will not fit on a single line, break it according to these general principles:

How to break the lines of method

How to break an arithmetic expression. The first example is preferred, since the break occurs outside the parenthesized expression, which is at a higher level.

How to indent method declarations. The first example follows the conventional practice. The second indents 4 spaces because the conventional indentation would shift the second and third lines too far to the right.

Line wrapping of If statements should generally use the 4-space rule, making it easier to see the body of the statement. For example:

Here are three acceptable ways to format ternary expressions:

Implementation comments are like those found in C++, which are delimited by /*...*/, and //.

Implementation comments are meant for commenting out code or for comments about the particular implementation.