Code Quality

Although there are coding standards put in place which include CheckStyle, PMD, and FindBugs rules, these rules are not used with their respective Maven plugins and the M2E code quality plugin. The code quality is validated using SonarQube instead of Maven or M2E.

The main reason for this choice is purely technical for the most part.

  • There were inconsistency and difficulty of getting Maven to generate the site correctly with the proper rules loaded and the exceptions of ignoring generated sources getting applied correctly.
  • It has issues running on M2E environment and the exclusion configurations do not always load up correctly.
  • In certain instances, we get build loops on M2E.
  • Using SonarQube allows the enterprise to manage the quality rules separately from the project.

For the non-technical reason, the Maven core plugins had changed their defect reporting policy making it difficult to report and have defects with their plugins addressed. Although this is relatively the same policy that SonarQube also has, there are less technical problems to deal with on SonarQube. The enterprise policy may change this later, however as of this time SonarQube is chosen.

OSS contribution standards

SonarCloud which is a hosted SonarQube installation is used and rules defined there are followed as much as possible (those that are not appropriate will be marked as either Won’t Fix or False Positive.

This is triggered from a Travis build and is integrated as part of the .travis.yml.

Issues with the approach

The problem with this approach is the lack of local and build-time testing as it now requires access to a SonarQube server to perform the tests rather than the IDE.

However, the reality of enterprise projects is technical debt is a norm and keeping that debt at zero may cause the business to miss the market.

In addition, the most of the bad practices are mitigated by:

  • using m2e-codestyle-maven-plugin which will configure the IDE to perform the necessary coding cleanups.
  • The Eclipse JDT already provides several errors/warnings for marking potential coding problems on the IDE.

Thereby reducing the need to have the extra analysis being performed by the IDE itself.