Skip to content
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

Closed
wants to merge 7 commits into from
Closed
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 56 additions & 0 deletions CODINGSTYLE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# Coding Style

Comment on lines +1 to +2
Copy link
Collaborator Author

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.

## Naming

1. Class names use CamelCase, for example: `class CallProfiler;`.
- Qt-related classes prepend an additional `R`, like `class RLine;`.
Copy link
Member

Choose a reason for hiding this comment

The 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:
Copy link
Member

Choose a reason for hiding this comment

The 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
Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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.
Additionally, I reformat the file.


4. Class members begin with `m_`.
Copy link
Member

Choose a reason for hiding this comment

The 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`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


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
Copy link
Collaborator Author

Choose a reason for hiding this comment

The 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.
Copy link
Member

Choose a reason for hiding this comment

The 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
Copy link
Member

Choose a reason for hiding this comment

The 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.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the discussion, I modify the rule of five.

Loading