Coding Guidelines

"A major benefit of object-oriented programming languages like C++ is the degree of reuse that can be achieved in well-engineered systems. A high degree of reuse means that far less code must be written for each new application; consequently, that is far less code to maintain." (G.Booch).

Software development distributed in space

As an object-oriented toolkit Geant4 is thought to be an integration of components (sets of classes) which are specific to high energy physics (HEP) applications or part of the general foundation class libraries, math libraries (commercial or free) already implemented and distributed world-wide, useful as building blocks for a wide variety of applications. Even within HEP, the reusability of object-oriented software across different laboratories and between different experiments will be essential.

Software development distributed in time

The first production version of GEANT4 was released in December 1998, after four years of R&D activity. At any time the toolkit may certainly be extended and refined by physicists and experts throughout the world. They may each have used or will use their own coding conventions and rules, which differ from one another. For a world-wide collaboration like GEANT4, it is therefore important not to impose rigid rules or style-conventions, but to maintain flexible and adequate guidelines for programming and coding styles.

"C++ was designed to support data abstraction and object-oriented programming in addition to traditional C programming techniques. It was not meant to force any particular programming style upon all users" (B.Stroustrup).

Programming Guidelines The following guidelines for using the features of the programming language aid adherence to the object-oriented paradigm (data-hiding, encapsulation, etc ...), and promote performance and portability (see Programming Guideline Motivations):

  • Every class should have at least one constructor and a destructor.
  • Each class should have an assignment operator and a copy constructor.
  • Data members should be made private/protected and in case accessed by inline functions.
  • The use of global variables or functions should be avoided.
  • The use of friend classes should be avoided where possible.
  • The use of type casting, especially from const* or const, should be avoided.
  • Hard-coded numbers within the code must be avoided; const should be used instead.
  • Instead of the raw C types, G4 types should be used.

Coding-style Guidelines The following coding-style guidelines promote code maintainability and readability (see Coding Style Motivations):

  • The public, protected and private keywords must be used explicitly in the class declaration.
  • Self-explanatory, English names for constants, variables and functions should be used.
  • The code should be properly indented.
  • Each GEANT4 class name should begin with G4.
  • Each header file should contain only one or related class declarations.
  • The implementation code for a class should be contained in a single source file.
  • Each header file must be protected from multiple inclusions.
  • Each file should contain a short header about the author, class description and date.

Guidelines for ISO/ANSI Compliant Code Using the following style guidelines will facilitate the porting of Geant4 to different systems/architectures:

  • Where possible, consider using the defined type G4String instead of STL std::string in the code.
  • Use the following keywords defined in global:
    G4cout, G4cerr, G4cin, G4endl
    instead of: cout, cerr, cin, endl.
    In every other case prepend std::. For example, for stream manipulators:
    std::ws, std::setprecision, std::setw.....
  • Prepend std:: for every STL type declaration. Example:
    std::vector myvector;