code-quality.md



Code quality level for RDD

Code Reviews
We want to ensure code review for all major commits, in gitflow for everything
that is subject to be merged into develop.
For projects with more than one developer in the team it is preferred to have code
reviews within the team, in other cases your friendly RDD developer team is
on your side.
The main idea is to invite all developers to a MR, at least 2 approvals needed for MR taking place. This way everybody
gets the chance to have a look at other people's code.

Sample Workflow: Code Reviews in SADE

A developer decides to work on a feature. She commits her changes to a separate feature branch. After some time she
finishes the feature and wants it to be integrated in the development branch.
The developer creates a merge request and assigns everybody she sees fit to properly review her code.
To avoid diffusion of responsibility, she also assigns one of the chosen assignees as MUST. This means that this
person has to approve the MR, otherwise the merge cannot be done. Although GitLab sends notifications to everybody who
is newly assigned to a MR, she should notify the MUST assignee personally (in case he or she doesn't notice the mail
sent by GitLab).
The MUST assignee reviews the changes according to style, variable naming, understandability, documentation
provided, functionality, etc. If everything is to his or her liking, he or she approves the MR. The other assignees are
free to review the code as well. Note: MRs without docs should not be accepted.
After the MR has been (dis)approved, the assignee removes his- or herself from the list of assignees. The MUST
assignee informs the developer over the review being finished.
The developer merges her changes into the development branch.


Proof of Concept
When preparing a proof of concept that is always labeled poc, a code review is
not necessary.