Goal

This page will define how to format

• Commit messages
• Branches
• Merge requests
• Issues
• Project structure
• code

Commits

Precise description of what has been done.

action(package): message feat(test...units): added functionality for ...

Action

• feat
• fix
• enhance
• refactor
• docs

Scopes should start with either main, test or pom If scope can be more detailed it should be followed by three dots "..." and finalized by the smallest common package folder.

Branches

action/short-message

action is going to one of the actions defined above. short-message should be one to four word seperated by a dash "-"

feat/create-tournament fix/member-not-found refactor/move-match-test enhance/calculating-match-result docs/format-review

Merge requests

merge request title should follow the formatting for commit messages

action(package): message See commmit for more information

A .gitlab directory will contain the configuration and templates for merge requests. Type of information that each merge request must contain is: Short description of what the merge request changes or adds. Description of what some of the key changes do. Using javadoc is acceptable. A list of all methods changed or added. Label the change as tiny, small, medium, large. Description of type of change or addition. At least one of the following needs to be added.

It should be written as class/location

subject of change

• method
• coupling
• field
• test

Statistics/method-field-inheritence-test list of affected parts of the code; method names, field names etc. Added class Statistics that tracks results in additon to times recieved a red card.

Issues

When writing an issue, it is important to go into as much detail as possible. For example when describing a bug, add as much information as possible. When requesting a feature, describe your idea, who it would benefit, and if possible: how to implement it.

Every issue should have a label. Examples of labels:

• bug
• feature request
• enhance
• help wanted
• refactor
• sprint nr x*
• prioritized*

*The last two aforementioned labels can only be assigned to an issue by the SCRUM master.

Project structure

Code

Example of a function:

class GenerateRandom {

    public int generateRandom(int param1, int param2) {
        int min = param1;
        int max = param2;

        int random_int = (int)Math.floor(Math.random() * (max - min + 1) + min);
		
        return random_int;
    }
		
    public static void main(String args[]) {
        System.out.println(generateRandom(10, 40));
    }

}

Use command prettier --write "**/*.java" to format code.

• Tabwidth is 4 spaces.
• Newline before return sequence, unless it is a oneliner.
• Space between arithmetic operators and parameters.
• Space to the write of commas before more parameters.
• Space before curly brackets: {}.
• First curly bracket on the same line.
• New line before a new function or end of a class.
• Always return a singular variable in a function for better readability.
• Imported items must be in alfabetical order.