|
|
# Quality management
|
|
|
|
|
|
To ensure the quality of the source code of the TeSSLa tools there are several criteria which the code in the master branch has to mach all time. To ensure this there are some checks included in the build process of the sub-projects.
|
|
|
|
|
|
## Testing
|
|
|
|
|
|
All relevant functions of the programs should be covered by unit and integration tests.
|
|
|
|
|
|
For Scala code a line coverage of more than 80 % should be reached.
|
|
|
|
|
|
## Coding Style
|
|
|
|
|
|
The coding style should apply to the following style guides:
|
|
|
|
|
|
* For Scala: Scala Style Guide (https://docs.scala-lang.org/style/)
|
|
|
* For C++: Google Style Guide (https://google.github.io/styleguide/cppguide.html)
|
|
|
|
|
|
The sub-projects use [scalafmt](https://scalameta.org/scalafmt/) and [clang-format](https://clang.llvm.org/docs/ClangFormat.html) to establish a clean style all time.
|
|
|
|
|
|
## Documentation
|
|
|
|
|
|
All compilation phases and relevant source files must be documented by Scaladoc/Doxygen comments.
|
|
|
All files also must contain copyright notices.
|
|
|
Public methods should contain Scaladoc/Doxygen documentation if they are non-trivial.
|
|
|
Private methods can contain Scaladoc/Doxygen documentation.
|
|
|
|
|
|
Changes implemented in a certain version are documented in the CHANGELOG file existing in every source repository |
|
|
\ No newline at end of file |