Improving your code - Overview

At this point, if you followed the Getting started section, you will have completed your first code analysis with SonarCloud. Congratulations!

Now we will move on to take a look at the key features and concepts of SonarCloud and how you can use them to improve your code quality and security.

Analyze early, analyze often!

SonarCloud is designed to be integrated into your daily development workflow so that analysis results are surfaced as early as possible each time you make changes to your code. The focus is on catching issues early in the cycle before they become embedded in the codebase.

SonarCloud provides multiple layers of defense to keep your code clean:

1. Catch issues before they even exist: In-IDE analysis with SonarLint.
2. Catch issues before they are committed to your main branch: Pull request analysis.
3. Catch issues every time you push to the main branch: Main branch analysis.

Catching issues in the IDE with SonarLint

SonarLint is your first line of defense against code quality and security issues. It can catch issues in your code right in your IDE, before you even push changes to your repository, using the SonarLint IDE extension.

SonarLint is available for:

• JetBrains IDEs, including IntelliJ IDEA, CLion, and others
• Visual Studio
• VS Code
• Eclipse

SonarLint works like a spell checker, highlighting issues in your code as you type. When an issue is identified, SonarLint provides you with clear remediation guidance so you can fix it right away. In many cases, it also provides a quick fix that can automatically fix the issue for you.

You can also connect SonarLint to your SonarCloud project. This allows SonarLint to leverage your team's quality profiles, synchronize other analysis settings and alert you to analysis results that appear at later stages in the dev cycle.

For more details, see Catching issues in the IDE with SonarLint.

Pull request analysis

Pull request analysis is your second line of defense against code quality and security issues, after SonarLint in the IDE. Issues that SonarLint cannot detect are detected by pull request analysis before they are merged into the main branch.

When you open a pull request (or, in GitLab, a merge request) SonarCloud will automatically analyze all (and only) the changes introduced by that pull request. The result is reported both in the pull request view of the SonarCloud interface and in your DevOps platform (GitHub, Bitbucket Cloud, Azure DevOps, or GitLab), as a pull request decoration. On every subsequent push to the pull request branch, the analysis is run again.

Each pull request analysis result displays a quality gate. The quality gate applies only to the actual code that was changed in the pull request. It can be set to prevent the merging of the pull request branch into its target branch if the analysis results do not meet your requirements.

For more details, see the Pull request analysis page.

Main branch analysis

Main branch analysis is your third line of defense against code quality and security issues, after SonarLint in the IDE and pull request analysis. Issues that neither SonarLint nor pull request analysis can detect are detected by main branch analysis.

Every time you make a change to the main branch of your project SonarCloud will automatically analyze all the code in the current state of the main branch.

The main branch results display a quality gate. The quality gate applies to all the code in the main branch. For more details, see Main branch analysis.

Keeping the focus on new code

SonarCloud provides developers with a host of insights into issues in their code. However, all this information is only useful if it can be acted upon to improve the code that is shipped. In many cases, the number of issues in a mature project can initially be quite large and developers can feel overwhelmed.

To address this, SonarCloud is designed with two principles in mind:

1. Focus on preventing issues from being introduced in the first place.
2. If issues are introduced, catch them early by always maintaining a focus on recent code changes.

The first point is covered by pull request analysis, as we saw above. The second is supported by main branch analysis.

The basic idea is to make the remediation of quality and security issues something you do as part of your normal feature-driven development work, and not a separate, daunting task.

We call this methodology Clean as You Code.

What counts as new code

As we have seen, the key to using SonarCloud effectively is to distinguish between new and old code. But, what counts as new and old can depend on the details of your project. So, SonarCloud allows the administrator of a project to control how that division is defined, by setting the project new code definition. See New code definition for the available options.

Because setting your new code definition is important, if it is not set, SonarCloud will make it clear by displaying a Not computed quality gate in your project overview and main branch summary, along with a link to Set the New Code Definition:

Once set, the new code definition is used to highlight new code throughout the SonarCloud interface. It is used to:

• compute the result for the default quality gate (see below),
• display the new and overall code tabs in the main branch summary,
• and display metrics and other information using the new/old distinction.

For more details, see the New code definition page.

Quality gates

The quality gate is an indicator that tells you whether your code meets your quality and security requirements. A failed quality gate means that your code does not meet these requirements:

A passed quality gate means that your code does meet these requirements and is ready to be merged or deployed:

Quality gate definition

In most cases, you will never need to adjust the definition of your quality gate, as the default quality gate built into SonarCloud (called the "Sonar Way" quality gate) is suitable for most projects.

But, you should still be aware that a quality gate is defined by a set of if-then conditions on analysis metrics. These are things like:

• If the maintainability rating is less than A, then fail
• If code duplication is greater than 1%, then fail

See Metric definitions for more details.

The default quality gate consists of a set of such conditions, which are applied only to new code. On a long-lived branch (like the main branch) this new code is defined by the new code definition. This is why you need to set a new code definition before the main branch quality gate will work. On pull request branches and other short-lived branches, the new code is defined as whatever has changed in that branch. The default quality gate is SonarCloud’s interpretation of the best way to deploy the Clean as You Code methodology.

However, as you become more advanced, you may wish to define your own quality gates.

See Quality gates for more details.