updated nomenclature doc

documentation/extra_doc/0_common.md

@@ -14,10 +14,10 @@ The `OMSimInputData` class (see `OMSimInputData.hh`) is responsible for processi
 
 The `OMSimMaterialHandler` class is the core component for creating and modifying materials. It provides several key methods:
 
-- `OMSimMaterialHandler::processMaterial()`: Creates a new material or modifies an existing one based on the data in the input file.
-- `OMSimMaterialHandler::processSurface()`: Processes and returns an optical surface defined in the input file.
-- `OMSimMaterialHandler::processExtraProperties()`: Adds additional properties to an existing material.
-- `OMSimMaterialHandler::processSpecial(ProcessorFunction p_processor)`: Handles special material types like IceCube ice or scintillators that require custom processing.
+- `OMSimMaterialHandler::processMaterial`: Creates a new material or modifies an existing one based on the data in the input file.
+- `OMSimMaterialHandler::processSurface`: Processes and returns an optical surface defined in the input file.
+- `OMSimMaterialHandler::processExtraProperties`: Adds additional properties to an existing material.
+- `OMSimMaterialHandler::processSpecial`: Handles special material types like IceCube ice or scintillators that require custom processing.
 
 Materials created via this class can be retrieved using Geant4's conventional method `G4Material::GetMaterial`. The `OMSimInputData` class also provides a wrapper method `OMSimInputData::getMaterial` to handle default parameters and special "argument materials".
 
@@ -33,7 +33,7 @@ Different materials may require different types of properties and processing. Th
 - IceCube ice, where the optical properties are calculated by the selected depth (an arg variable)
 - Scintillator materials with complex decay time and yield properties
 
-Special processors for these materials are implemented in separate namespaces (e.g., `IceProcessor`, `ScintillationProcessor`) and can be passed to the `ProcessSpecial` method of `OMSimMaterialHandler`.
+Special processors for these materials are implemented in separate namespaces (e.g., `IceProcessor`, `ScintillationProcessor`) and can be passed to the `OMSimMaterialHandler::processSpecial` method.
 
 ### Geometry Data
 

documentation/extra_doc/2_technicalities.md

@@ -23,6 +23,55 @@ auto [counts, edges] = Tools::histogram(data, 5);
 ---
 ---
 
+## Nomenclature
+
+We follow these naming conventions:
+
+Methods:
+- Written in camelCase, starting with a lowercase letter
+- Example: `calculateDistance()`
+- Note: This contrasts with Geant4's methods, which always start with an uppercase letter
+
+Classes:
+- Written in PascalCase (also known as UpperCamelCase)
+- Core framework classes should start with `OMSim`
+- Example: `OMSimDetectorConstruction`
+
+Member Variables:
+- Prefix: `m_`
+- Written in camelCase after the prefix
+- Example: `m_particleEnergy`
+
+Global Variables:
+- Prefix: `g_`
+- Written in camelCase after the prefix
+- Example: `g_worldVolume`
+
+Function Parameters:
+- Prefix: `p_`
+- Written in camelCase after the prefix
+- Example: `p_initialPosition`
+
+Local Variables
+- Start with a lowercase letter
+- Written in camelCase
+- Example: `localParticle`
+
+Namespaces
+- Written in PascalCase
+- Example: `ToolsNamespace`
+
+By adhering to these conventions, we aim to:
+1. Clearly distinguish OMSim code from Geant4 code (so we can for example find+replace code without worries)
+2. Easily identify the scope and purpose of variables and functions
+3. Maintain consistency throughout the codebase, enhancing readability and maintainability
+
+Remember to apply these conventions consistently across all new code and when refactoring existing code.
+
+---
+---
+
+
 ## Matching PMT Efficiency to Measurements
 
 In order to simulate the PMT efficiency correctly, each photon is given a weight that corresponds to the detection probability ([click here](md_extra_doc_0_common.html#autotoc_md5) for more details). These weights are calculated using data files to match measurements. These data files have to be generated for each new PMT that is to be added to the framework. The module `efficiency_calibration` facilitates this procedure. In the following, the mDOM PMT is used as an example.