For development setup, see Development Guide below.
Please review these details before committing, especially for AI-generated code.
- Keep changes minimal — do not add what is not necessary.
- Comments are not always better when abundant. Ideally, the code should be self-explanatory.
- Files must end with a newline.
- Use Markdown syntax (backtick-fenced) for identifiers in comments and error messages.
- Comments and error messages must be in English.
- Comments and error messages should follow the language's conventions first. If the language does not specify, use complete sentences — capitalize the first letter and end with punctuation.
- Unless specified in Adapt New Models, follow the Google C++ Style Guide strictly. Use the default
.clang-format. - Error and warning messages follow the LLVM Coding Standards.
- Initializer list order must match member declaration order.
- Formatted by
scripts/format.py
Unless specified in Adapt New Models, follow PEP 8 as the primary style guide. For anything PEP 8 does not cover in detail, refer to the GDScript style guide—while it targets a different language, its non-syntax conventions are still applicable.
Formatted by scripts/format.py
-
Comments should be complete English sentences, starting with a capital letter and ending with punctuation. Use Markdown syntax when referencing code within comments.
-
Docstrings: Follow PEP 257 conventions.
-
Formatted by
scripts/format.py
Commit messages must follow Conventional Commits.
Existing commit messages may follow the "issue/### - " legacy format with an issue created to describe the case.
- Small PRs should be squashed. Large PRs may keep multiple commits, but each commit must be meaningful and well-formed.
- PR titles should respect to issue number and case summary.
- Before merging (or after each stage of changes), build and test on major involved platforms. Include the results in PRs.
Branch names use the format <type>/xxx-yyyy-zzzz, where <type> matches the PR title's Conventional Commits type, and words are joined with hyphens.
Existing branch names may use the legacy format issue/###, followed by a suffix when necessary.
Refer to ReadMe and Adapt New Models
- to be populated