Guidelines

Coding Guidelines

• Indentations should use 4 spaces, not tabs.
• There should be 1 empty line between function.
• A function should do only one thing and have a name that describes that action.
• Functions which could be hard to understand at a first glance should have a comment (/* ... */) above them describing their action.
• If necessary .blade.php files may contain comments ({{-- ... --}}) as well.
• If a variable will not change during runtime 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 over to the next line.

Naming Conventions

• Function and class names use PascalCase.
• variable names use snake_case.
• 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.