This document outlines the coding style guidelines for the PhasicFlow codebase.
Adhering to these guidelines ensures consistency, readability, and maintainability of the project.
## 1. FormattingIndentation:
* Use 4 spaces for every logical level and block.
* Line Spacing: Leave two empty lines between sections (e.g., between functions in a .cpp file, between class members).
## 2. Naming ConventionsGeneral Naming:
* All names should start with lowercase letters, except for special names (e.g., Ergun, Hertz).
* Macro names start with Upper case or all the letters are in UPPER case.
* Compound Names: For compound names, the first word starts with a lowercase letter, and subsequent words start with an uppercase letter (e.g., boundaryBase, motionModel).
## 3. File Structure
* Header Files: Use the .hpp extension for header files.
* Source Files: Use the .cpp extension for source files.
* Header and Source File Headers: All header and source files must include a standardized header that describes the project's intention and licensing information.
* File Naming: Header and source file names should correspond to the class they contain. Aim for one class per file.
* Inline Functions: Place inline functions in a separate classNameI.hpp file to avoid cluttering the main header file.
## 4. Class DesignClass Member Order:
* Private members and methods
* Private static members and methods
* Public methods
* Public static methods
* Enumerations and Nested Classes: Declare enumerations and nested classes before all class members and methods.
* Special Functions: Each class must explicitly define all special functions:Constructor, Copy constructor and assignment operator, Move constructor and assignment operator
* Destructor: Each class must have an explicit destructor declaration:`~className() = default`; or `~className();`
* Interface classes or classes with virtual methods must have a virtual destructor.
* Virtual Method Overrides: When implementing a `virtual` method from a base class in a derived class, use the `override` keyword. The same applies to derived class destructors.
## 5. NamespacesOfficial Namespace:
The official namespace for the codebase is pFlow. All entities should be defined within this namespace.
provide the documentations in the header files only. In rare cases where you are generating documentations for executables, the doxygen documentation can be supplied in the .cpp file.
* **General Doxygen Style:**
* Use `///` for short documentations for methods and members.
* Use `/** */` for classes and main methods which play a significant role in the class or code.
* Place Doxygen comments *before* the declaration of the entity being documented (e.g., class, function, variable).
* Use `@param` to document function parameters, `@return` for return values, `@brief` for a short description, and `@details` for a more in-depth explanation.
* Use Markdown syntax within Doxygen comments for formatting.
* **File Headers:** Each file should contain a Doxygen comment at the top, including:
*`@file` : The name of the file.
*`@brief`: A brief description of the file's purpose.
*`@author`: The author(s) of the file.
*`@date` : The date of creation or last modification.
* **Class Documentation:**
* Use `/** */` for class documentation.
* Provide a `@brief` description of the class.
* Use `@tparam` to document template parameters.
* Document the purpose of the class, its invariants, and how it should be used.
* **Function/Method Documentation:**
* Use `///` for short documentations.
* Use `/** */` for main methods which play a significant role.
* Provide a `@brief` description of the function.
* Use `@param` to describe each parameter, including its purpose and whether it is an input, output, or input/output parameter.
* Use `@return` to describe the return value, including its meaning and possible values.
* Use `@pre` to document any preconditions that must be met before calling the function.
* Use `@post` to document any postconditions that will be true after the function returns.
* Use `@throws` to document any exceptions that the function may throw.
* Use `@details` for a more detailed explanation of the function's behavior, algorithms, or any other relevant information.
* **Variable Documentation:**
* Use `///<` for single-line documentation of variables.
### 6.2. Doxygen Documentation Examples
* **Class example**
```cpp
/**
*@brief Represents a particle in the simulation.
*@details This class stores the position, velocity, and other physical
* properties of a particle.
*/
class Particle
{
private:
Point position_; ///<Thecurrentpositionoftheparticle.