Improving code quality

SonarQube helps developers and organizations improve code quality by focusing on code that’s added or changed.

Focus on new code

SonarQube’s approach to code quality focuses on Defining new code — code that has been added or changed according to your new code definition. As a developer, you focus on maintaining high standards and taking responsibility for the code you’re working on today. SonarQube gives you the tools to set those standards and verify that your code meets them.

The Defining new code can be set at different levels (global, project, and, starting in Developer Edition, at the branch level). Depending on the level at which your new code definition is set, you can change the starting point to fit your situation.

For more information on setting your new code definition, check out Defining new code.

Tracking new code trends

To get a visual representation of new code trends based on the data in your projects, navigate to More > Clean as You Code in SonarQube.

Personal responsibility

You own the quality and security of the new code you are working on today. You aren’t responsible for anyone else’s code. If you add new issues, SonarQube automatically assigns them to you so you can maintain the quality of your work.

For more information on issues and how they are assigned, check out the Issues page.

Quality gate

Your Quality gates is a set of conditions that tells you whether or not your project is ready for release. A well-configured quality gate should:

• Focus on new code metrics – When your quality gate is set to focus on new code metrics (like the built-in Sonar way quality gate), new features are delivered at a consistently high standard. As long as your quality gate is green, your releases will continue to improve.

• Set and enforce high standards – When standards are enforced on new code, you can focus on meeting those standards in your code without worrying about pre-existing issues. If a project doesn’t meet these standards, it won’t pass the quality gate and is not ready to be released.

• Be a reliable measure of code quality – When you consistently have a passing quality gate, you have a clear indication that developers are maintaining high standards on all new code.

For more information on quality gates and to make sure your quality gate is enforcing your standards, check out the Quality gates page.

Recommended quality gate conditions

A recommended quality gate for new code ensures that:

• No new issues are introduced

OR

• Reliability Rating for new code is not worse than A

• Security Rating for new code is not worse than A

• Maintainability Rating for new code is not worse than A

In addition, they ensure that the following criteria are met:

• All new security hotspots are reviewed

• [Configurable] New code has limited duplication

• [Configurable] New code is properly covered by tests

The duplication and test coverage conditions are configurable to your specifications. The other conditions are locked and cannot be edited while maintaining a recommended configuration.

To ensure that your new code always meets your standards, we recommend including the "No new issues are introduced" condition in your quality gate. You can do this by clicking the Review and Optimize Quality Gate button if your quality gate is already compliant, or the Review and Fix Quality Gate button if your quality gate is not compliant.

For more information, see Quality gates.

You should always focus on new code, so we do not recommend adding conditions for overall code to your quality gate.

Pull request analysis

You can use pull request analysis and pull request decoration to make sure that your code meets your standards before merging. Pull request analysis lets you see your pull request’s quality gate in the SonarQube UI. You can then decorate your pull requests with SonarQube issues directly in your DevOps platform’s interface.

For more information on setting up pull request analysis and pull request decoration, see the documentation on Pull request analysis.

Potential drawbacks of stricter quality gates

The recommended quality gate is designed to achieve high-quality increments of code with the least amount of friction in the development process. Adding more conditions may lead to bottlenecks in development pace with minimal benefit. Frequent failures can also cause debate about which conditions to prioritize, increasing the risk that the quality gate is ignored.

Adding conditions on overall code shifts focus away from new code to old code, making it harder for developers to take ownership of their own work.