Skip to content
This repository has been archived by the owner on Mar 27, 2022. It is now read-only.

Development guidelines

Afonso Jorge Ramos edited this page Feb 26, 2019 · 1 revision

Git Workflow Guidelines

One Line Summaries

Before your full commit message, use a one-line summary of the change as this improves the output of GitHub’s rendering of changes done to the project.

After this one line change, you can add the regular, full-documented version of the change.

Pull/Merge Requests

All Pull/Merge Requests must be approved by two developers of the main team who were not directly involved in the development of the features/bug-fixing/changes done on the to-be-merged branch. Merge must be done by the last of the approvers.

When a Merge Request is not ready for being merged, add the WIP: prefix to the Merge Request's title. This will prevent in from being merged, denoting Work In Progress

Pull/Merge Requests must have descriptive names in kebab-case

Coding Guidelines

Indentation

We use tabs, not spaces.

Names

Use MACRO_CASE for preprocessor statements
Use PascalCase for enum values
Use camelCase for function and method names
Use camelCase for property names and local variables
Use whole words in names when possible

Types

Do not export types or functions unless you need to share it across multiple components

Do not introduce new types or values to the global namespace

Strings

Use "double quotes" for strings shown to the user that need to be externalized (localized)

Use 'single quotes' otherwise (valid for JavaScript and PHP only)

All strings visible to the user need to be externalized

Style

Only surround loop and conditional bodies with curly braces if they are bigger than one liners

Curly braces never go on the same line as the code they surround.

Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:

for (var i = 0, n = str.length; i < 10; i++) { }
if (x < 10) { }
function f(x: number, y: string): void { }

Specific guidelines for C

All C coding guidelines are automatically enforced by running the linter, except for the format of names, which should follow the above rules. If you want to know the specifics of these guidelines, check the .clang-format file used by the linter.

Specific guidelines for PHP

All PHP coding guidelines are enforced by the PHP linter.