Development standards

Code Style

Follow the Google C++ guidlines. We brought some modifications to their code style guidlines.

You can find the .clang-format file at the root of the repository.

Branch name
Use kebab-case for branch names.

Example:

+ feat/server/packet-hello-world // OK
- Feat/Server/PacketHelloWorld   // KO - The branch name is in PascalCase
- feat/server/packet_hello_world // KO - The branch name is in snake_case

Variable names
The variable names are in camelCase.

Example:

+ int myVariable = 42;                         // OK
+ std::string anotherVariable = "Hello world"; // OK
- int invalid_variable_name = -21;             // KO - The variable name is in snake_case

Class attributes
Class attributes must start with _.

Example:

class MyClass {
  private:
+  int _myAttribute;  // OK
-  int myAttribute;   // KO - The attribute does not start with _
-  int myAttribute_;  // KO - The attriute ends with _
}

Method names
The functions / methods name is in camelCase.

Example:

class MyClass {
  public:
+  int fooBar();  // OK
-  int bar_foo(); // KO - The method name is in snake_case
}

Brackets placement

For classes, functions, structures, use the Allman style:

class MyClass
{
    // ...
}

For the rest (if, for, while, etc.), use K&R style:

namespace {

void foo()
{
    if (true) {
        // ...
    }
}

}

Note

There is a shell binary to check for errors before commiting. folder_name must be the name of the folder to check the files in.

./checker.sh {folder_name}

use -h for usage.

Important

Library include folder header should only contain the user-dedicated header files and the files that said headers need.

VCS Workflow

Important

Make sure you ran this command before making any commit.

git config core.hooksPath .githooks

1. Create a new branch starting from dev before altering code.
2. Each branch must follow this format: type/scope/details
   • feat/scope/details
   • fix/scope/details
   • ref/scope/details
   • hotfix/id/details

Note

Here are some branch name examples :

Branch Name	Type	Scope	Details
feat/lib/rtnt/packet	feat	lib/rtnt	packet
fix/server/cli-parsing	fix	server	cli-parsing

3. Before updating dev:
   • Rebase dev -> current_branch
   • Fix potential conflicts
   • Create Pull Request current_branch -> dev
   • Rebase the pull request

Warning

Complete the template's checklists.

4. Before merging into main:
   • Rebase main -> dev
   • Fix potential conflicts
   • Create Pull Request dev -> main
   • Rebase the pull request

Warning

Complete the template's checklists.

5. Use this form of git karma:
   • Feature: feat(scope): description
   • Fix: fix(scope): description
   • Refactor: ref(scope): description
   • Fixing coding style: style(scope): description
   • Example: feat(server>protocol): Added new packet type

Important

Use a preterit action verb for the description

6. Specify whole scope in the commit message (ex: server>ecs>player)
7. For main and dev, PR must be reviewed by at least 1 member
8. Releases must be validated by all members
9. Create Releases
10. Create Issues and sub-issues for features with the follow title format : type(scope): Description (where the scope is such as rtecs, rtnt, rteng, client, server, wiki, ...)

Example:

Note

Keep in mind that this a pure example for representation purpose.

• Issue:
  • title: Packet Hi
  • description: Create a Hi Packet
  • additional context:

    - The server should be sending this packet to the client upon successful connection
    - *Anything possibly useful* 

  • Then follow the pre-submission checklist
  • sub-issues:
    • title: Receive Hi
    • description: Create a Hi Packet receiver in the client side
    • additional context:

      - The server will be sending this packet to the client upon successful connection
      - The client must handle the deserialization
      - The client must handle the packet
      - *Anything possibly useful*

    • Then follow the pre-submission checklist
    • title: Send Hi
    • description: Create a Hi Packet sender in the server side
    • additional context:

      - The server will must send this packet to the client upon successful connection
      - The server must handle the serialization
      - The server must handle basic connection
      - *Anything possibly useful*

    • Then follow the pre-submission checklist