Coding conventions and style guide

Files

In general, every .cc file should have an associated .h file. There are some common exceptions, such as unittests and the .cc files containing just a main() function.

A correct use of header files can make a huge difference to the readability, size and performance of your code.

The following rules will guide you through the various pitfalls of header and source files.

1. Use forward declarations where possible.
2. In #ifndef-#define guards, use the name of the class in capital letters + _H at the end.
3. Use trailing underscores for data members.
4. Add a brief description of the purpose of the class (also in .cc files). Use an existing class as an example of the format.
5. Try not to copy and paste the #include from another class, because you'll end up with a lot of them that you'll not use. Keep them to the minimum set needed by your code.

In macro files, group the commands of the same class and use the same order as in one of the existing files.

Line length

The length of each line of code should be at most 80-100 characters. A developer should not change the indentation of someone else's code, unless the line is longer than 100 characters.

Volume names

Since it is quite inconvenient to have long names in the output files, the names of the geometry volumes must be kept under 20-30 characters. Brevity is good.

Exceptions

When using the G4Exception class use the following convention:

G4Exception("[ClassName]", "Function()", Exception, "error message")

Git commit style

We are using common conventions described, for instance, in this page.

Tags

NEXUS tags have this format: vX_Y_Z. X is incremented when a major change is introduced, or when it breaks backward compatibility. Y is incremented when a new functionality is added to the code (for instance, a new geometry, or a new generator) and Z is incremented when a bug of an already existing functionality is fixed.