rasdaman Code Guide: Rules

Rule 0: Every time a rule is broken, this must be clearly documented.


Rule 1: Include files in C++ must have a file name extension .hh.

Rule 2: Implementation files in C++ must have a file name extension .cc.

Rule 3: Inline definition files must have a file name extension .icc.

Rule 4: Every file must include information about its purpose, contents, and copyright. For this purpose, the following standard headers are provided: Source Header, Include Header, Inline Source Header, Make Header. Adjust the copyright to your name / instituion as deemed adequate. All code must use a GPL header, except for files in the raslib/, rasodmg/, and rasj/ directories, which must use an LGPL header.

Rule 5: All method definitions must start with a description of their functionality using the Standard Method Header.

Rule 6: All comments must be written in English.


Rule 7: Every include file must contain a mechanism that prevents multiple inclusions of the file.

Rule 8: Never use path name in #include directives. Only use relative paths and the parent path (..) is not allowed.

Rule 9: Never have indirect inclusion of a function. Collective include files are allowed.


Rule 10: The names of variables and functions must begin with a lowercase letter. Multiple words must be written together, and each word that follows the first starts with an uppercase letter (Camel Casing).

Rule 11: The names of constants must be all uppercase letters, words must be separated by underscores ("_").

Rule 12: The names of abstract data types, structures, typedefs, and enumerated types must begin with an uppercase letter. Multiple words are written together and each word that follows the first is begun with an uppercase letter (Camel Casing).


Rule 13: The public, protected, and private sections of a class must be declared in that order (the public section is declared before the protected section which is declared before the private section). See the standard class definition for details.

Rule 14: No member functions within the class definition include file. The only exception are inline functions.

Rule 15: No public or protected member data in a class. Use public inline methods (setVariable() and getVariable()) to access private member data.

Rule 16: A member function that does not affect the state of an object (its instance variables) must be declared const.

Rule 17: If the behavior of an object is dependent on data outside the object, this data must not be modified by const member functions.


Rule 18: A class which uses new to allocate instances managed by the class must define a copy constructor.

Rule 19: All classes which are used as base classes and which have virtual function, must define a virtual destructor.

Rule 20: A class which uses new to allocate instances managed by the class must define an assignment operator.

Rule 21: An assignment operator which performs a destructive action must be protected from performing this action on the object upon which it is operating.


Rule 22: A public member function must never return a non-const reference or pointer to member data.

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


Rule 24: Do not use unspecified function arguments (ellipsis notation).

Rule 25: The names of formal arguments to functions must be specified and are to be the same both in the function declaration and in the function definition.


Rule 26: Always specify the return type of a function explicitly. If no value is returned then the return type is void.


Rule 27: A function must never return a reference or a pointer to a local variable.

Rule 28: Do not use the preprocessor directive #define to obtain more efficient code; instead, use inline functions.


Rule 29: Constants must be defined using const or enum; never use #define.

Rule 30: Do not use numeric values directly in the code; use symbolic values instead (Use constants for default values). Always document the meaning of the value.


Rule 31: Variables must be declared with the smallest possible scope. Do not use global variables.

Rule 32: Never declare multiple variables in the same line.

Rule 33: Every variable that is declared must be given a value before it is used.

Rule 34: Don't use implicit type conversions.

Rule 35: Never cast an object to a virtual class.

Rule 36: Never convert a const to a non-const.


Rule 37: The code following a case label must always be terminated by a break statement.

Rule 38: A switch statement must always contain a default branch which handles unexpected cases.

Rule 44: Never use goto.


Rule 45: Do not use malloc,realloc or free, but use new and delete. In general, use C++, not C code.

Rule 47: Always provide empty brackets ([]) for delete when deallocating arrays.

Rule 48: Use C++ exception handling (try/catch) for every possible failure situation.


Rule 49: When submitting a patch, describe concisely in the commit message what has been accomplished in the patch. In case of a fix, include in the message the ticket# fixed and place a comment in the source file

at the location the fix was done mentioning the ticket (best by its URL).

Last modified 5 years ago Last modified on May 30, 2012 1:16:18 PM