Conventions guideline
Global coding conventions guideline
-
The project’s code and its related documentation must be written in English.
-
Uses of
TODO
andFIXME
is permitted and followed using SonarQube. Don’t create a new Github issue when adding a newTODO
orFIXME
. Create an issue to fix previousTODO
orFIXME
.
OpenApi contract
-
Endpoint paths must be plural.
-
GET
endpoints must specify the field on which the object is retrieved :/objects/id/{id}
. -
POST
endpoints should be used to create a new object -
PUT
endpoints should be used to update an object with same syntax asGET
(/objects/id/{id}
)
Java related coding conventions guideline:
-
No implicit use of curly brackets.
-
When adding new Dtos, favor using
record
if it’s possible. Otherwise, set private attributes, and only add their getters. Convert those that do not respect this rule. -
Repository classes are created with parsimony to avoid breaking SOLID principles when needed. When repository classes ares created, they must not have business rules. Business rules must be implemented in "Service" classes.
-
No implicit use of the final keyword. It can only be used explicitly and for a set purpose.
-
Use
String.formatted()
method for concatenation. -
Favor constructor injection over
default package
field injection. -
Use AssertJ assertions instead of Junit.
mapstruct
mappers
Project uses mapstruct in order to map objects from entity classes to Dto classes and vice versa.
-
mappers interfaces must be suffixed by
Mapper
-
all target fields must be mapped or set explicitly as
ignored
(check by global compilation optionunmappedTargetPolicy
) -
used component model is
jakarta
to permit injection using@Inject
annotation fromjakarta.inject
(configured globaly by compilation optiondefaultComponentModel=jakarta
)
Code quality check
-
Coding conventions will be enforced by SonarQube.
-
Try to fix sonar issues on files impacted by your changes using the plugin
sonarLint
. -
We strongly recommend using Sonar Lint with the project specific SonarQube profile.