Screenshot of a Sonarqube Project Dashboard

SonarQube is now one indispensable tool we use every day to check our success in coding with quality. It enforces us to be better with state-of-the-art way of coding, styles, provide more testing to our projects and work better as a team -ensuring maintainability, readability, and low complexity.

  • Code Statistics: General Statistics for the scanned code. Total lines of code, files, directories and so on can be found here.
  • Maintainability: How hard can be to understand, change, correct and possibly reuse existing code? Taking in to account all issues, a maintainability rating is calculated. Possible ratings are: A (best), B, C, D or E (worst).
  • Duplications: Amount and percent of total sequences of code duplicated. Duplications can be a burden for maintainability and reusability is severely affected. These issues are resolved using refactorization techniques.
  • Technical Debt: Represents the overall average time/money required to fix all the issues found. As you can see, this has the highest impact on the development team/QA team, clients and Product Owners.
  • Issues: Several types of issues are being analysed here: vulnerabilities (possible security breaches), bugs (code that should not work in some scenarios) and code smells (deprecated styles and code approaches to problems). These are defined by profiles which contain a bunch of rules, most of them defined by recognized/experienced specialists in programming languages.
  • Complexity: How many possible outcomes has a function or method? When a condition is found, for instance, two possible parts of code can be executed, which means you need to take both into account when analyzing the code, increasing the level of complexity, of needed insight. High complexity leads to forgetting real outcomes and error-prone situations, bad maintainability and so on. You can find more about it here.
  • Unit Tests: Testing is a big part for Quality Assurance. Unit tests are meant to provide a way of testing a unit (atomic part of code, such as the affirmative part of a condition or throwing an error if validation failed) and these are accumulated to provide a more robust and error-free code. Coverage is meant to express how much of the lines of code and files were covered (invoked, used, tested) after the unit tests were run. A low coverage means that a lot of tests have to be implemented to really test all the possible use cases present in code.