You can choose a password length of not more than 50 characters. Do not forget to switch keyboard layout to the English. Do not choose a password too simple, less then 4 characters, because such a password is easy to find out. Allowed latin and [email protected]#$%^&*()_-+=., characters

Control source code quality using the SonarQube platform

In this article we'll look at the main features of SonarQube - a platform for continuous analysis and measurement of code quality, and we'll also discuss advantages of the methods for code quality evaluation based on the SonarQube metrics.

SonarQube is an open source platform, designed for continuous analysis and measurement of code quality. SonarQube provides the following capabilities:

- The support of Java, C, C++, C#, Objective-C, Swift, PHP, JavaScript, Python and other languages.
- It provides reports of code duplication, compliance with the coding standards, unit tests coverage, possible errors in the code, density of comments in the code, technical debt and much more.
- It saves the history of metrics and builds charts of the changes in the metrics over the time.
- It provides a fully automated analysis: integrates with Maven, Ant, Gradle and common continuous integration systems.
- Allows integration with such IDEs as Visual Studio, IntelliJ IDEA and Eclipse using the SonarLint plugin.
- It provides integration with external tool: JIRA, Mantis, LDAP, Fortify and so on.
- You can extend the existing functionality using third-party plugins.
- It implements the SQALE methodology to evaluate the technical debt.

A SonarQube quality model implements the SQALE methodology (Software Quality Assessment based on Lifecycle Expectations) with certain improvements. As it is well known, the SQALE methodology focuses mainly on the complexity of the code maintainability and does not take the project risks into account.

For example, if there is a critical security problem detected in a project, the strict following SQALE methodology requires you to address all the existing reliability issues, changeability, testability and so on and only then go back to the new critical problem. In fact, it's much more important to focus on fixing new bugs, if potential problems have been living in the code for quite a long time and there were no user bug reports.

Taking that into account, SonarQube developers have modified the quality model, based on SQALE to focus on the following important points:

- The quality model should be as simple as possible
- Bugs and vulnerabilities should not get lost among the maintainability issues
- Serious bugs and security vulnerabilities in the project should lead to the fact that the Quality Gate requirements aren't met
- Maintainability issues of the code are important too and cannot be ignored
- The estimation of the remediation cost (using the SQALE analysis model) is important and should be carried out

The standard SonarQube Quality Gate uses the following metric values to assess if the code has passed the checks successfully:

- 0 new bugs
- 0 new vulnerabilities
- technical debt ratio on the new code <= 5%
- the new code coverage is not less than 80%

Sonar team has defined 7 deadly sins of developers that increase the technical debt: