Guidelines

Coding Guidelines

• Indentations should use 4 spaces, not tabs.
• There should be 1 empty line between functions.
• Functions may only do 1 action and the neme should represent the action accurately.
• Functions which could be hard to understand at a first glance should include comments (/* ... */) above them describing their action.
• If necessary .blade.php files may contain comments ({{-- ... --}}) as well.
• If possible use Artisan to generate files, instead of making them manually.
• Avoid data manipulation inside .blade.php files.
• For recurring bits of front-end code use Blade's subviews.
• Front-end layout should be defined in Blade's components.
• Use Blade's CSRF protection.
• Avoid raw php inside .blade.php files.
• Do not use html commenting (<-- ... -->).
• If a variable does not change during execution it should be marked as const.
• A variable name should always describe it's value. No ambiguous names such as $a or $b. Simple variable names are only allowed when used as a counter inside of a loop.
• Avoid global and static variables.
• Bool variable names should always be confirming. Correct example: $is_avaiable, incorrect: $is_not_available.
• const variables have to be declared as you would any other variable, do not use define().
• Prefer condition-level return statements over root-level return statements. See example below (Pseudo-code):

public function IsFileReadable(file) {
    if(file.exists()){
        try {
            file.read();
            return true;
        }
        catch(error) {
            return false;
        }
    }
    else return false;
}

• Avoid return statements not returning any value.
• Do not use continue.
• A comma is always followed by a space.
• Operators are always surrounded by spaces.
• A code block is opened on the same line as it's definition.
• A code block is ended on a separate.
• Lengthy conditions should jump to the next line.

Naming Conventions

• Function and class names use PascalCase.
• variable names use snake_case.
• private variable names are prepended with an underscore.
• const variable names use SCREAMING_SNAKE_CASE.
• Files generated with Artisan get named automatically. Do not change these names after generation.
• Files have different case types depending on their purpose, be consistent inside folders.

GitHub Guidelines

Branching Rules

• For each userstory each user is allowed to make their own branch. The user branch should be directly based on dev and has the following format: <UserstoryNr>_<User>.
• Aside from user branches. Hotfix branches based on dev are also allowed.
• Main is updated once per sprint. (Every 2 weeks)

Review Rules

• 4 reviews are required to merge from dev into main.
• 2 reviews are required from any branch into dev. (Excluding the code owner's review)
• Reviews should come with useful feedback. Not just criticism.
• Use the Code Highlight tool.
• Merge conflicts should be solved by the merge request's owner.
• Draft merge requests don't have to be reviewed. If it is a draft be sure to mark it with the WIP label.
• The merge request owner is responsible for the assigning reviewers.

Issue Rules

• Use the issues for bugs, glitches and thrown errors.
• An issue should include how to reproduce the issue.
• An issue should include the expected result and current result.
• If a pull request solves an issue, connect it to the issue.