@@ -25,25 +25,74 @@ In short, when you submit code changes, your contributions are understood to be
2525We use GitHub issues to track bugs. Report a bug by opening a new issue, it's that easy!
2626
2727## Coding Conventions
28- * Interfaces starts with ` I ` .
29- * Abstracts starts with ` A ` .
30- * Class names: ` UpperCamelCase ` .
31- * Public member variables: ` lowerCamelCase ` .
32- * Private member variables: ` m_lowerCamelCase ` .
33- * Public static variables: ` UpperCamelCase ` .
34- * Private static variables: ` s_lowerCamelCase ` .
35- * Function/Method arguments: ` p_lowerCamelCase ` .
36- * Function/Method names: ` UpperCamelCase ` .
37- * Constants: ` kUpperCamelCase ` .
38- * Class member variables are located at the bottom of the file.
39- * Avoid using macros to define constants; prefer using ` constexpr ` instead.
40- * Tabs are preferred over spaces.
41- * Always end your files with an empty line.
42- * Avoid aligning variable names and values using tabulations.
43- * Scope blocks should start on a new line.
44- * Comment your functions, enums, classes, methods ([ Javadoc style] ( https://en.wikipedia.org/wiki/Javadoc ) )
45-
46- ** Some coding conventions may have been overlooked during the writing of this document, so always refer to the existing codebase.**
28+ ### File Header
29+ Every file must include the following header:
30+ ``` cpp
31+ /* *
32+ * @project: Overload
33+ * @author: Overload Tech.
34+ * @licence: MIT
35+ */
36+ ```
37+
38+ ### Naming
39+ | | |
40+ | -| -|
41+ | N.1 | Custom Types (* structs* , * classes* , * enums* , * typedefs* ) use the ` UpperCamelCase ` notation. |
42+ | N.2 | Functions & methods use the ` UpperCamelCase ` notation. |
43+ | N.3 | Variables use the ` lowerCamelCase ` notation (unless specified otherwise, see below). |
44+ | N.4 | Private member variables are prefixed with ` m_ ` (e.g. ` m_elapsedTime ` ). |
45+ | N.5 | Function parameters are prefixed with ` p_ ` (e.g. ` p_enabled ` ). |
46+ | N.6 | Compile-time constants are prefixed with ` k ` followed by ` UpperCamelCase ` (e.g. ` kPi ` ). |
47+ | N.7 | Do not use abbreviations. |
48+ | N.8 | Interfaces are prefixed with ` I ` , abstract classes with ` A ` , and enum types with ` E ` . |
49+ | N.9 | Enum values are in ` SHOUT_CASE ` . |
50+
51+ ### Formatting
52+ | | |
53+ | -| -|
54+ | F.1 | Curly braces must be placed on their own lines, except for the opening brace of lambdas. |
55+ | F.2 | Code must be indented using tabs. |
56+ | F.3 | Keep a low indentation level (use early returns, split functionalities, reduce complexity). |
57+ | F.4 | Always use braces for scopes (* if* , * for* , * while* , etc.). |
58+ | F.5 | Avoid single line ` if ` statements (e.g. ` if (condition) return 0; ` ). |
59+ | F.6 | Always end your files with an empty line. |
60+ | F.7 | Avoid aligning variable names and values using tabulations. |
61+
62+ ### Classes
63+ | | |
64+ | -| -|
65+ | C.1 | Members are ordered by access level (` public ` , ` protected ` , ` private ` ). |
66+ | C.2 | Methods always come first, followed by member variables. |
67+
68+ ### Includes
69+ | | |
70+ | -| -|
71+ | I.1 | Includes are in lexicographic order with lowercase precedence (e.g. ` aa ` , ` aA ` , ` Aa ` , ` AA ` ). |
72+ | I.2 | Included file paths are fully specialized (` Project/Namespace/File.h ` ). |
73+ | I.3 | Include statements use brackets (` <> ` ) over quotation marks (` "" ` ). |
74+
75+ ### Documentation
76+ | | |
77+ | -| -|
78+ | D.1 | Document public types, methods, and functions using the [ Javadoc style] ( https://en.wikipedia.org/wiki/Javadoc ) . |
79+
80+ ### General
81+ | | |
82+ | -| -|
83+ | G.1 | Almost always avoid * macros* . Use ` constexpr ` whenever possible. |
84+ | G.2 | Always use forward slashes when it comes to paths. |
85+ | G.3 | Prefer anonymous functions over private methods when possible. |
86+ | G.4 | Avoid declaring multiple classes in a single header file. |
87+ | G.5 | Prefer stack allocations over heap allocations. |
88+ | G.6 | Almost always avoid manual heap allocations (` malloc ` , ` new ` , ` delete ` ). |
89+ | G.7 | Avoid raw pointers (use smart pointers when required). |
90+ | G.8 | Use ` std::array ` over dynamic collections (e.g. ` std::vector ` ) when the size is fixed. |
91+ | G.9 | Use ` std::string_view ` , ` std::span ` , and * const references* whenever possible. |
92+ | G.10| Prefer composition over inheritance. |
93+ | G.11| Use assertions to validate inputs when type checks aren't sufficient. |
94+
95+ * Note: Some coding conventions may have been overlooked during the writing of this document, so always refer to the existing codebase.*
4796
4897## Thanks!
49- Thanks for being a part of the Overload Tech. team!
98+ Thanks for being a part of the [ Overload Technologies ] ( https://github.com/Overload-Technologies ) team!
0 commit comments