0

I'm confronted to a huge "spaghetti code" with known lack of documentation, lack of test covering, high complexity, lack of design rules to be follow, etc. I let the code be analysed by a default sonar-scan, and surprisingly for me, the maintability has a really great score with a technical debt of 1,1% ! Reality shows that almost each change introduce new bugs

I'm quite perplex, and wonder if some particularities in the implementation could explain this score... We have for example quite a lot of interfaces (feeling 4-5 Interfaces for 1 implementation), uses reflexion and service locator pattern.

Are there other indicator that I could use that would be eventually more relevant for improving the quality?

Loic Mouchard
  • 1,121
  • 7
  • 22
  • What is the project's Maintainability Rating (letter grade)? – G. Ann - SonarSource Team Oct 28 '16 at 12:53
  • try adding sqale pyramid widget might help. Also it could be that Sonar default rules are not looking for violation of coding practice inside your organization... http://www.sqale.org/blog/the-sqale-pyramid-a-powerful-indicator this should help you in understand pyramid. – Shiva Oct 28 '16 at 14:19
  • @G.Ann-SonarSourceTeam : the Maintainability Rating is A. – Loic Mouchard Oct 28 '16 at 16:01
  • @Shiva, I installed the current version of SonarQube 6.1. It seams that the sqale plugin has been removed in version 5.5, see: http://docs.sonarqube.org/display/PLUG/SQALE+Plugin – Loic Mouchard Oct 28 '16 at 16:20

1 Answers1

2

The maintainability rating is the product of the estimated time to fix all the issues of type Code Smell in your code base versus the estimated time to write the code in its current state.

You should also look at the Bugs and Vulnerabilities in the code base.

Regarding your specific points (and assuming we're talking about Java):

  • known lack of documentation - there is a rule in the default profile that looks for Javadocs. You might read its description and parameter values to see what it does an does not find.
  • lack of test coverage - there is currently a "hole" in this detection; if there is no coverage for a class, then the class is not taken into account when computing lines that could/should be covered, and therefore when calculating coverage percentages. It should be fixed "soon". The first steps will appear on the platform side in 6.2, but will need accompanying changes in the language plugins to take effect.
  • high complexity - there are rules for this. If they are not finding what you think they should, then take a look at their (adjustable) thresholds.
  • lack of design rules - the only rule that might address this (Architectural Constraint) is
    1. deprecated
    2. slated for removal
    3. not on by default dropped from the latest versions of the plugin
  • use of reflection - there aren't currently rules available to detect this
G. Ann - SonarSource Team
  • 22,346
  • 4
  • 40
  • 76