• Development
• Coding Style Guidelines
• Commit Guidelines
  • Commit Style
• PR Guidelines
• Fork / Branch Guidelines
• Comments / Docs

Development

These guidelines are there to facilitate working together on the same project. They are of course subject to change, but should lead to a more consistent development experience.

Coding Style Guidelines

The repository contains a .clang-format file that defines the coding style. This style is enforced by a pipeline running on every merge request, rejecting it when the conditions are not met.

You can use clang-format directly on your code, or set up your IDE to format your code automatically. Please use Version 17! On Windows, just use this exe:

clang-format.exe

To automatically make Rider use this, you can set it in the settings:

Commit Guidelines

General commit best practices apply. The main important thing is to encapsulate your commits to a single purpose. Do not to mix two features into one commit. Avoid mega commits, and keep them as concise and small as possible!

Commit Style

To make the git history and especially git blame easier to read, we're tryig to follow Conventional Commits. This forces you to think about what you put into one single commit, and makes it much more readable for everyone else.

The style is as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

where type can be, but is not limited to (if you have good reasons):

• fix
• feat
• docs
• style
• ci
• refactor
• chore

and scope:

• interaction
• movement
• replication
• pawn
• cave

These are of course also subject to change/discussion, but should give a general starting point.

PR Guidelines

• The same general guidelines from commits also apply to pull/merge requests. Keep them as encapsulated as possible and avoid mega PRs that nobody wants to review.
• If you have changed uassets that are often touched, like e.g. the pawn, make small incremental changes such that merging will not be an issue if other people also work on the pawn.

Fork / Branch Guidelines

• The main repository should only contain the branches: 4.XX, 5.XX, 4.XX-dev, 5.XX-dev. Keep feature branches in your own fork to not spam the repository.
• Use your fork to create PRs onto the 5.XX-dev branches.
• Never commit directly onto the main 5.XX branches. Only PRs from the dev branches will be accepted there.

Comments / Docs

We currently have no unified comment/doc style. However, the general comment guidelines apply:

• Use meaningful comments, don't just state the obvious. Actually describe why things are like that.
• Try and comment as much as possible, things that are obvious to you might not be obvious to somebody else!