Is your feature request related to a problem? Please describe.
Operaton aims to provide a high quality. We use Sonarqube to perform static code analysis on the code base. The findings Sonar is showing need to be resolved. Not all findings need to be resolved by code changes.
We have to be careful about potential API changes, which have to be avoided, because we must not break users of C7 CE. For example, Sonar might report to reduce the visibility of fields, or perform renamings to comply to conventions. Within test code this is feasible since test code is not considered API. But in main code we have to be careful about this.
Furthermore, refactorings that change the code implementation should be thoroughly tested. The test coverage is already ok, but when the changed code is not covered new tests might be needed.
Describe the solution you'd like
Visit the open findings on Sonarqube.
What you want to resolve does not matter, there are plenty open findings. Be it per class, package, or finding type. For the latter, select the "Rule" drop down and browse for rules.
Best is to group changes that solve the same finding rule, or per class/package per commit. Make PRs of moderate size, or larger when they contain trivial repeating changes.
Overall, help us to reduce the open issues on Sonar.
Is your feature request related to a problem? Please describe.
Operaton aims to provide a high quality. We use Sonarqube to perform static code analysis on the code base. The findings Sonar is showing need to be resolved. Not all findings need to be resolved by code changes.
We have to be careful about potential API changes, which have to be avoided, because we must not break users of C7 CE. For example, Sonar might report to reduce the visibility of fields, or perform renamings to comply to conventions. Within test code this is feasible since test code is not considered API. But in main code we have to be careful about this.
Furthermore, refactorings that change the code implementation should be thoroughly tested. The test coverage is already ok, but when the changed code is not covered new tests might be needed.
Describe the solution you'd like
Visit the open findings on Sonarqube.
What you want to resolve does not matter, there are plenty open findings. Be it per class, package, or finding type. For the latter, select the "Rule" drop down and browse for rules.
Best is to group changes that solve the same finding rule, or per class/package per commit. Make PRs of moderate size, or larger when they contain trivial repeating changes.
Overall, help us to reduce the open issues on Sonar.