| Version 1.9 Build 1556
|
|
Next: Code Review Process
Up: Standards and Guidelines
Previous: Documentation and Naming
Subsections
#include only those header files your class absolutely requires. Use
forward declarations when that will suffice.6.14
Avoid protected data members, using protected member functions for access
to private data instead.
Do not return pointers or references to private data, except to accomodate
Fortran or C libraries, or if efficiency absolutely requires it.6.15
Virtual functions in a derived class shall be explicitly labelled with
the virtual keyword in the class declaration, even though this is
not required by the language.
Indicate unfinished or questionable code with the documentation extractor's
tag <todo>.
Provide definitions for all of the standard member functions which the
compiler would (otherwise) generate automatically: default
constructor6.16,
destructor6.17,
copy constructor, and the assignment operator. For any of
these which you really wish to disallow, declare them private, and create
minimal implementations (if any at all). For example:
...
private:
SomeClass () {;} // disable the default constructor
...
Functions shall be declared so that their arguments (parameters) appear in
this order: output parameters first; input/output parameters next;
input parameters last.6.18 Functions which return only one value
should usually use the function's return-value to return that value, rather
than add an additional output parameter to the parameter list. If
a function modifies its single argument in place, then that
argument is best understood as an input/output argument.6.19
Specify formal arguments and default parameters in the function declaration;
use the same names in the function
definition.6.20
Constructors with one argument should
be made explicit, or have an explanation why automatic conversion is wanted
(as an example: Unit(String) is an obvious candidate for automatic
conversion, to be able to write e.g. ``km/s'' rather than Unit(``km/s'')).
Specify explicit return types for all functions. Return an appropriate
integer value from main.
All functions that do not change the state of
the class should be declared const. If only the ``hidden'' state (like
a cache) changes, the function should be declared const, but with a
mutable cache variable. mutable should be used carefully.
Multi-line compound statements should have
braces. E.g.
if (condition) {
statement1;
} else {
statement2;
};
Minimize the number of template arguments by
utilising the typename construct for user classes, and the traits methodology for fundamental types.6.21
Only C++ style casting is allowed. The use of
reinterpret_cast is not allowed. Allowed are: static_cast,
const_cast (but be aware of what you are doing) and dynamic_cast.
(*)
Macros (especially #if type, should be limited
to the include guard. Other cases should be checked with the QAG,
who often can point out other solutions.
Exceptions should be reserved for truly exceptional circumstances, and
not used to replace status flags or condition tests. Exceptions should be
documented with the <thrown> tag (and maybe with the thrown declaration
specifier).
All code should compile without producing warnings from the
compiler. Most compilers do not produce many spurious warnings any more.
Next: Code Review Process
Up: Standards and Guidelines
Previous: Documentation and Naming
  Contents
  Index
Please send questions or comments about AIPS++ to aips2-request@nrao.edu.
Copyright © 1995-2000 Associated Universities Inc.,
Washington, D.C.
Return to AIPS++ Home Page
2006-10-15