-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write the coding-style guide for Modmesh #362
Changes from all commits
4ebd550
0595df0
cfc0736
4fc0850
6326549
5cca9ac
9177d7d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,56 @@ | ||
# Coding Style | ||
|
||
## Naming | ||
|
||
1. Class names use CamelCase, for example: `class CallProfiler;`. | ||
- Qt-related classes prepend an additional `R`, like `class RLine;`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just say "Qt classes". It is redundant to write "-related". |
||
* A class is considered Qt-related if its parent class belongs to the Qt library. | ||
|
||
2. Variable names and using-declarations use snake_case: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is incorrect to say using-declarations. The use case you mentioned is type aliasing: https://en.cppreference.com/w/cpp/language/type_alias . Please correct. |
||
- Example variable: `R3DWidget * viewer;` | ||
- Example using-declaration: `using size_type = std::size_t;` | ||
|
||
3. Qt-related function names use CamelCase, while non-Qt-related function names use snake_case. | ||
- Functions are Qt-related if they belong to a Qt-related class. | ||
- Example Qt-related function: `QMdiSubWindow * RManager::addSubWindow(Args &&... args);` | ||
- Example non-Qt-related function: `void initialize_buffer(pybind11::module & mod);` | ||
Comment on lines
+5
to
+16
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I distinquish and define the Qt-related classes and functions in the list. |
||
|
||
4. Class members begin with `m_`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Only C++ |
||
|
||
5. [Macros](https://en.cppreference.com/w/cpp/preprocessor/replace) start with `MM_DECL_`. | ||
|
||
6. [Using-declarations](https://en.cppreference.com/w/cpp/language/using_declaration) end with `_type`. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think you mistake with https://en.cppreference.com/w/cpp/language/type_alias . |
||
|
||
7. Acronyms within names should be treated as words instead of using ALL_CAPS_CONSTANTS. | ||
- Example classes: `class HttpRequest;` | ||
- Example function: `void update_geometry_impl(StaticMesh const & mh, Qt3DCore::QGeometry * geom);` | ||
Comment on lines
+24
to
+26
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here is the naming rule about acronyms. |
||
|
||
Certainly! Here's a more coherent version: | ||
|
||
## Comments | ||
|
||
1. Comment blocks should follow [Doxygen style guidelines](https://www.doxygen.nl/manual/docblocks.html). | ||
|
||
2. For one-line comments like `/* end of NamespaceOrClassName */`, | ||
place them at the end of namespaces or classes. | ||
Example usage: | ||
```c++ | ||
namespace modmesh | ||
{ | ||
// More code... | ||
}; /* end of modmesh */ | ||
``` | ||
|
||
3. It is highly recommended to include references in comment blocks. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just say it is recommended. |
||
|
||
## Formatting | ||
|
||
1. Ensure there is a blank line between the definitions of classes and functions. | ||
|
||
2. Long lines should be divided into shorter ones. | ||
- For C++, no specific line length limit is set. | ||
- For Python, adhere to an 80-character limit per line. | ||
|
||
## Class | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's more accurate to use "Constructors" as the subject. |
||
|
||
1. It's advisable to explicitly define constructors and destructors for classes whenever possible. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. According to the discussion, I modify the rule of five. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remove the introduction, and modify the filename to CODINGSTYLE.md.