Basic & Extended Examples Coding Guidelines

Version 2.1 Proposal

Name conventions

  1. Class names are defined within a single namespace, specific to each example. Eg. B1, B2, etc. for the basic examples. Class names without a prefix can be still defined in the categories where this convention is already in use.*
  2. Class member functions start with an upper case letter.
  3. Class data members start with a prefix "f" followed with an upper case letter. This convention makes easier to understand the code.
  4. Local variables and functions argument names start with a lower case letter except for the names starting with known acronyms in capital case letters.

Coding rules

  1. Declare overriding virtual functions in the header files with keyword override.
  2. Initialize class data members using default member initializer in the class definition (.hh). Both initialization with braces or assignment are possible. This prevents from use of uninitialized values.
  3. Do not introduce dummy functions or classes if they have no use in the example.
  4. The UI commands defined in the example should be used in the cdash test macro(s) as much as possible.

Style rules

  1. Avoid using long lines (more than 100 characters) where possible.
  2. Avoid using tabulators.
  3. Each function implementation in the .cc file should be preceded by the agreed separator line.
  4. Avoid using more than one empty lines or personalized separators in the code.

Documentation

  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.
  2. The files with C++ code start with a standard header including Geant4 copyright 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.
  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.
  4. All macros provided with the example should be documented in README.

Application conventions

  1. It is recommended to define materials with using NIST manager unless there is a specific reason for explicit material definition.
  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.
  3. G4UIExecutive should be instantiated at the same beginning of main() if interactive mode is enabled, just after arguments processing if present. This makes possible to handle the output and eventual exception via the Geant4 UI since the beginning of running example.

These rules should be applied in addition to the Geant4 Coding Guidelines for developers: http://geant4.web.cern.ch/geant4/collaboration/coding_guidelines.shtml