Conventions
IGUANA packages must follow the following conventions. Only imported packages under
Ig_Imports are exempt from these rules.
Naming conventions
- All package and class names must begin with the prefix "Ig". Words in the name must have first letter capitalised, and then combined together (no intervening slashes or underscores).
- All method names must begin with lower case latter. Subsequent words must be connected with first letter capitalised and no other intervening separators.
- Header files must have extension ".h".
- C++ source files must have extension ".cc".
File structure conventions
- Header and source files must be named by the (main) class and must in general have only one class per file. Several classes can be defined in a single file only if they are very tightly coupled (e.g. a container and its iterator).
- Header files should have a guard that includes both the package name and the header file name. The guard should be in all capitals, with words separated with underscores. You are encouraged to use the IGUANA emacs templates as these use the right convention (you can use "C-c g" to insert the header guard, for example if you have renamed a file).
Use of CVS and ChangeLog maintenance
- If the package has a ChangeLog file, keep it up to date. If the file is there, never commit a change without mentioning it in ChangeLog -- there is no point in having the file it is doesn't mention all the changes. Lassi has a convenient utility in his ~/bin directory called clcommit that extracts the change description from ChangeLog and uses it to check in files into CVS. In emacs, you can easily add a ChangeLog entry with "C-x 4 a"; note however that in general we do not mention the subdirectory names like src or interface as they are obvious. Otherwise your change descriptions should follow the example already set in the IGUANA packages. You should also refer to the Guile project's "Maintaining the ChangeLog" guide.
- If the package does not have a ChangeLog file, always check in changes with some meaningful message that describes the changes you have made.
Plug-in registration conventions
- Rep mappings are registered as
Runtime/Reps/Model/Representable capabilities. Here Model and Representable are typeid().name() of the model and representable application object classes, respectively.
- Run-time loaded service components are registered as
Runtime/Services/ServiceName[/Rest].
- GUI extensions for all Qt-based application are registered under
Extensions/GUI/Qt/Name.
- OpenInventor extension node libraries are registered as
Extensions/Inventor/NodeKits/Name.
- Geant4 run-manager setup extensions are registered as
Runtime/Geant4/Setup/Setup Area/Name.
- Geant4 run-manager extensions are registered under
Runtime/Geant4/Run Manager.
- Geant4 visualisation shape extensions are registered under
Extensions/Geant4/Visualisation.
Session registration conventions
- SoQt internal state is registered under Runtime/SoQt.
- Geant4 services install themselves under Runtime/Geant4 (Run Manager, Vis Manager).
- Qt application support services install themselves under Runtime/Application/Qt (Context, Crash Alert, Debug, Mainloop, Menu, Status Bar, Tool Bar).
Home
User
