docs: add cpp style guide

docs/maintainer_guides/cpp_style_guide.md

@@ -0,0 +1,92 @@
+# C++ Style Guide
+
+## Naming
+
+### Directory Names
+
+In snake case, e.g. `my_directory`
+
+### File Names
+
+In pascal case, e.g. `MyFile.cpp`. For single-class files, the filename should be consistent with the class name.
+
+### Type Names
+
+In pascal case, e.g. `MyClass`. Names of all types including classes, structs, type aliases, enums and type template parameters should follow this rule.
+
+### Variable Names
+
+#### Common Variable Names
+
+In camel case, e.g. `myVariable`.
+
+#### Class and Struct Data Members
+
+For non-public ones, in Hungarian, e.g. `mMyMember`.
+
+For public ones, in camelCase, e.g. `myMember`.
+
+### Constant Names
+
+In Pascal case, e.g. `MyConst`.
+
+### Function Names
+
+In camel case, e.g. `myFunction`.
+
+### Namespace Names
+
+In lower case, e.g. `my_namespace`.
+
+### Enumerator Names
+
+In pascal case, e.g. `MyEnumerator`.
+
+### Macro Names
+
+In upper snake case, e.g. `MY_MACRO`.
+
+## Comments
+
+### Comment Style
+
+Use `// ...` for end-of-line comments. Use `/* ... */` for mid-line comments. Use `/// ...` for Doxygen comments.
+
+### File Comments
+
+Start each file with license boilerplate.
+
+If a source file (such as a .h file) declares multiple user-facing abstractions (common functions, related classes, etc.), include a comment describing the collection of those abstractions.
+
+### Struct and Class Comments
+
+Every non-obvious class or struct declaration should have an accompanying comment that describes what it is for and how it should be used, including at least a brief introduction and public attribute description.
+
+For separated classes, e.g. `.h` and `.cpp`, comments should go with header files.
+
+### Function Comments
+
+Including at least a brief introduction, parameter and return value description, and exception description.
+
+### Variable Comments
+
+#### Class Data Members
+
+All public members should have a comment.
+
+#### Global Variables
+
+All global variables should have a comment describing what they are, what they are used for, and (if unclear) why they need to be global.
+
+### Implementation Comments
+
+In third-person tense.
+
+### Function Argument Comments
+
+If function arguments are not clear, comments should be added, e.g. `/*count=*/`.
+
+### TODO Comments
+
+TODOs should include the string TODO in all caps, followed by the issue ID and the description referenced by the TODO, e.g. `// TODO(#1234): Update this list after the Foo service is turned down.`.
+

mkdocs.yml

@@ -29,6 +29,9 @@ nav:
 
     - API 🔗: https://levilamina.liteldev.com/api
 
+  - Maintainer Guides:
+    - maintainer_guides/cpp_style_guide.md
+
 exclude_docs: |
   api/assets/
 
@@ -102,5 +105,6 @@ plugins:
             Tutorials: 教程
             How-to Guides: 如何做到···
             API 🔗: 接口 🔗
+            Maintainer Guides: 维护者指南
 
   - search