Quality Gate indicator Clean as You Code

A New Day Dawns for
Code Quality and Security

Clean as You Code means focusing on New Code for maximum Code Quality impact with minimum investment.

You can focus on New Code for maximum Code Quality impact with minimum investment.

Traditional approaches to Code Quality face challenges
that the Clean as You Code method erase.

Focus on New Code
to maintain project health

The SonarQube project homepage highlights the Code Quality and Security of your New Code (changed or added) so you can focus on what's important: making sure the code you write today is solid.

Developers own quality
in New Code

As a developer your priority is making sure the code you write today is clean and safe.

The dashboard highlights the Code Quality and Security of your New Code

Challenge | Feedback comes late in the process

The right feedback, the right time, the right place.

From SonarLint to PR analysis to the New Code Period in the project homepage, SonarQube gives you the tools to stay on track.

Connect Sonarlint to SonarQube

SonarLint in your IDE is your first line of defense for keeping the code you write today clean and safe. Connect to your SonarQube instance to make sure you're applying the same rules that will be used during SonarQube analysis.

Sonarlint is available in Eclipse IDE Sonarlint is available in IntelliJ IDEA Sonarlint is available in Visual Studio IDE Sonarlint is available in VS Code IDE
PR Analysis DE Available on Developer Edition EE Available on Enterprise Edition DCE Available on Data Center Edition

Use SonarQube pull request analysis and decoration to make sure your code is top-notch before you merge - and maybe even before you ask for human review.

Pull Request analysis available in Bitbucket Pull Request analysis available in GitHub Pull Request analysis available in Azure DevOps

Challenge | No one owns quality

Personal responsibility, not heroics

With the Clean as You Code methodology, no one is responsible for cleaning up someone else’s code. You only have to do an okay job on the code you’re writing today.

And if you do add new issues, they’ll be automatically assigned to you, so no one is asked to clean up after someone else.

Developers own quality in their own New Code.

Developers have personal responsibility for their own New Code

Challenge | Pushback from teams

Quality Gate™

Enforcing a Quality Gate focused on New Code metrics makes sure new features are delivered cleanly. Then all you need to do is keep your Quality Gate green to make sure each release is better than the last.

Foster high standards with New Code focus

There's no downside to setting - and enforcing - high standards in your Quality Gate if you're only applying them on New Code. Developers take pride in meeting high standards on their New Code and if the project doesn't pass its Quality Gate it's obviously not ready to release.

Teams embrace meeting high standards on their New Code.

Keep the Quality Gate green to make sure each release is better than the last

Management owns quality in Old Code

The first time you analyze a legacy project the results can be alarming, but digging into old code for no other reason than fixing legacy debt brings the risk of functional regression.

As a manager, you own Code Quality and Security in old code. Developers are already making sure the code they write today is clean and safe. It's up to you to decide whether it's important to clean up old code and to prioritize and schedule the cleanup if it is.

Managers have responsibility for deciding whether it's important to clean up old code.
Technical debt remediation: side effect of business-as-usual

Developers own quality in New Code; managers own quality in old code. But even without active cleanup, in the normal course of business the code base will gradually be cleaned up anyway as developers touch old code to make new changes.

Areas of code that are modified frequently will be fixed quickly, making future maintenance of those high-traffic areas easier, cheaper, and more reliable. Less-trafficked areas of code will be cleaned up more slowly, but the fact that they're not impacted by user requests means they're less crucial and can afford to wait.

The code base will gradually be cleaned up
pull request Example of lines of code with an issue SonarQube's dashboard of continuous inspection

Ready to Clean as You Code?

Get SonarQube