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
     only.
     
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
     example. 
     
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 
     easily.

     
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 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: 
http://geant4.web.cern.ch/geant4/collaboration/coding_guidelines.shtml)