Introducing New Clean as You Code criteria

We are introducing a simplified quality criterion to make sure that your new code is always clean!

What are Clean as You Code criteria and why are they important?

Clean as You Code criteria are the quality criteria that will keep your new code clean. As you might know, keeping the new code clean is fundamental to the Clean as You Code methodology.

This criteria is part of the built-in quality gate and can be configured in any of your custom quality gates.

Practice for clean code:

Make sure that your quality gate is passing (green) for every pull request merger and routinely on your branches. This way your new code stays clean. Always.

Screenshot 2023-10-23 at 13.48.46

Improved Clean as You Code criteria in Sonar way

With our commitment to continuously improve SonarQube and SonarCloud as solutions for clean code, we are enhancing the existing “Clean as You Code” criteria. This new update aims to provide an even more robust framework to ensure that all newly developed and modified code consistently meets the highest quality standards.

Sonar way quality gate represents SonarSource’s recommended quality criteria for your new code.

Sonar way will use a brand new condition starting from SonarQube 10.3 release and soon in SonarCloud.

New code has 0 issues !

With the new Clean Code approach, issue types (bug, vulnerability, and code smell) are deprecated. They are all issues now. You may read more here. With this change, the new code is expected to have zero unresolved issues to pass the quality gate.

This condition replaces conditions on security, reliability, and maintainability in the older version of the Sonar way quality gate.

You can customize coverage and duplication conditions with a custom Clean as You Code compliant quality gate (custom quality gates with any conditions of your choice can still be created).

Adapting to new Clean as You Code criteria

The Clean as You Code methodology focuses on new code, this new stricter criteria is applied only to your new code based on your project’s New Code Definition. This means the number of issues to be resolved will be limited.

If your quality gate fails, consider the following options to resolve open issues:

  • We recommend you fix all open issues in the new code
  • If you prefer not to fix an issue you may resolve it with a suitable option.

After upgrading to SonarQube 10.3: If your team cannot yet adopt the new criteria:

You can switch back to the previous version of Sonar way quality gate. Among your your quality gates, you can find Sonar way(legacy) quality gate, which is a backup of the old Sonar way. Assign this quality gate to your projects or set it as default.

Our recommendations:

  • Use Sonar way quality gate or a custom Clean as You Code compliant quality gate on as many projects as possible. This way your team can be on the optimal path to Clean Code.
  • Fix your custom quality gates to include Clean as You Code criteria.
  • Review your project’s New Code Definition, if you feel that the new code period is too long and results in too many issues in the new code scope.

Please feel free to ask any questions or to share feedback here.


What about the possibility to track issues independent to the quality gate like this rule?
java:S1309 Track uses of “@SuppressWarnings” annotations

As it is now it is not possible to use this tracking feature by marking those rules as non relevant for a quality gate.


Better example: There are rules in many languages about tracking code that you have marked as deprecated, so that you remember to remove it some day. These rules appear to often be part of the Sonar Way profile. The implication of always having no issues of new code is that you can’t annotate anything as deprecated when using the Sonar Way profile.

If only there was a way to resolve the introduction of these as out of scope, then it would make sense. Because after all, these rules fundamentally aren’t compatible with clean as you code.


Thank you very much for your excellent feedback @reitzmichnicht and @torgeir.skogen.

I see the need for the ability to manage issues that are ideally fixed at a later point. We will consider an improved solution for this use case.