---
# System prepended metadata

title: Coding Conventions

---

# Coding Conventions

Important: Before commiting, run `npm run lint` in the frontend-folder and  `mvnw checkstyle:checkstyle` in the backend folder.

[[_TOC_]]

## Naming Conventions

All names except for control variables in loops are descriptive and in english or recognizable as abbreviations of english words.

### Package names

Package names are lowercase and do not use underscores.

### Class names

Naming of classes and interfaces follows upper camel case.
Test classes are named starting with the name of the class they are testing, and ending with Test.

### Constant names and enum value names

Constants and values of enum classes are named in upper case. 

### Other

Naming of local variables, field names, methods and parameters follows lower camel case.

 

## Formatting and Indentation

### Braces

Braces are used for code blocks of if, else, for, do and while statements, even when the body is empty or contains only a single statement.
For nonempty blocks, the braces follow the K&R style (Egyptian brackets).

### Block indentation

Backend: The indent increases by four spaces when a new block is opened.
Frontend: The indent increases by four spaces when a new block is opened.

### Statements

Only one statement per line is used, a statement is followed by a line break.

### Whitespace

Vertical whitespaces (blank lines) are used between independent blocks like the class variable block, constructors and methods. Additional line breaks may be used for formatting at your own discression.
Horizontal whitspaces are in any case used between if, for and catch and the following open parentheses ((), between a closing curly brace (}) and a following else or catch and on both sides of any binary or ternary operator. Additionally, they may be used where deemed suitable.

### Annotations

Annotations applying to a class, method or constructor appear immediately after the documentation block, and each annotation is followed by a line break.

### Comments

Implementation comments may be used but are optional. For Javadoc-comments please see [Documentation Guidelines]().
Block comments are indented at the same level as the surrounding code. 
Java/TS: For single line comments both the single-line-style (//) or the multi-line style (/* */) may be used. For multi line comments, each new line starts with a *.

## Programming practices

### Annotations

@Override is always used when overriding a superclass method or implementing an interface method. @Autowired is used also for constructors.

### Exceptions

Layer specific exceptions are written as checked exceptions and need to be caught and wrapped. Unspecific exceptions (NotFoundException, ..) may be passed through.

### Software architecture

The architecture follows the single responsibility principle see [Single-Responsibility-Prinzip](https://de.wikipedia.org/wiki/Single-Responsibility-Prinzip). 