Coding Guidelines Final

Submitted by Anonymous (not verified) on Wed, 06/28/2017 - 11:25
Novice & Extended Examples Coding Guidelines

1. Name conventions

1.1. Classes in common use names starting with the prefix 'EG4';
if there are more than one classes of the same name,
then all classes names are followed by a number: (00), 01, 02, 03 ...
The number 00 should be used for helper classes which are not supposed to
be directly usable in user application, eg. physics list with geantino

1.2. Classes in extended examples (features) use names with a prefix, specific
to the demonstrated feature and different from the one reserved for
classes in common, or names without a prefix.

1.3. Class member functions start with an upper case letter.

1.4. Class data members start with a prefix "f" followed with an upper case
letter. This convention makes easier to understand the code.

1.5. Local variables and functions argument names start with a lower case
letter except for the names starting with known acronyms in capital
case letters.

2. Coding rules

2.1. Re-declare virtual functions in the header files with keyword virtual,
as it makes easier to see which functions are prescribed in the
base class (and usually called by kernel)

2.2. Provide the initialization list of the class data members (and base class
if present) in all class constructors. This prevents from use of
uninitialized values.

2.3. Do not introduce dummy functions or classes if they have no use in the

2.4. All commands implemented in messengers should be demonstrated in a run
macro (can be done also via commented lines) so that users can test them

3. Style rules

3.1. Avoid using long lines (more than 80 characters) where possible,
avoid using tabulators.

3.2. Each function implementation in the .cc file should be preceded
by the agreed separator line.

3.3. Avoid using more than one empty lines or personalized separators
in the code.

4. Documentation

4.1. Each example is provided with a README text file and its modified
version .README.txt for automatic generation of the Web documentation
with Doxygen. The latter differs from the former only by the modifications
needed for a correct representation of the file on the Web.

4.2. The files with C++ code start with a standard header including Geant4
copyright, the CVS Id keyword and a file description.
The comment lines with a file description start with /// (instead
of standard //) in order to be recognized by Doxygen, on the first line
followed by the keyword \file.

4.3. Each class contains a description of the class functionality placed
just before a class definition in the class header file (.hh)
The comment lines with a class description start with /// (instead
of standard //) in order to be recognized by Doxygen.

5. Application conventions

5.1. It is recommended to define materials with using NIST manager
unless there is a specific reason for explicit material definition.

5.2. It is recommended to use the physics list classes and physics
builders provided in Geant4 unless there is a specific reason
for using an explicitly defined physics list.

These rules should be applied in addition to the Geant4 Coding Guidelines
for developers: