Quality standards and new code

SonarQube warns you whenever issues are detected in your new code. When you add new code to your projects, you usually touch a portion of the old code in the process. As a consequence, analyzing and cleaning new code allows you to fix issues in your old code and gradually improve the overall quality of your codebase.

Defining a quality standard

First, you define the code quality standard for your project: 

• With a quality profile, you define the set of rules to be applied during analysis. We recommend using the built-in quality profile, called Sonar way.  See Quality profiles.
• With a quality gate, you define a set of conditions that the code must meet. By default, SonarQube implements a recommended quality gate called the Sonar way. See Quality gates.

Then, you define what is considered new code in your project, adapting your configuration to the nature of your project: versioned, continuous delivery, etc. 

Finally, you ensure your code is analyzed frequently and at different stages of its journey, in your IDE and your DevOps platforms. See SonarQube for IDE documentation.

Focus on new code

New code is code that you've recently added or modified. Different options can be used to define new code on a branch, project, or at global level. The new code definition tells SonarQube which part of the code is considered new during analysis.

SonarQube Server differentiates the analysis results on new code from overall code (overall code includes new and old code). To ensure you focus your efforts on new code, SonarQube Server highlights the status of new code in the UI. 

Likewise, the built-in Sonar way quality gate defines conditions applying to new code only.

New code definitions

SonarQube Server supports the following options for new code definition: Previous version, Number of days, Specific analysis, and Reference branch.

Except for the Reference branch option, SonarQube Server calculates a new code period with a start and end date. All the code that falls between the date of your last analysis and the start date is considered new code. The way the start date is calculated depends on the applying new code definition option. For information about the issue date calculation, see Issue management solution overview. 

Previous version

Any code that has changed since the most recent version increment of the project is considered new code. 

With this option, the new code period's start date is the date of the first analysis performed for the current project version. 

Available at the global, project, and branch levels.

The current version of a project is determined in different ways depending on the build system:

• If the analysis is done using the SonarScanner for Maven, then SonarQube Server reads the version from the  pom.xml  file.
• If the analysis is done with the SonarScanner for Gradle then SonarQube Server reads the version from the  build.gradle  file.
• In all other cases, the version must be explicitly specified by setting the analysis parameter  sonar.projectVersion .

Number of days

Any code that has changed in the last X days is considered new code. 

With this option, the new code period's start date is the current date minus X days.

For example, setting the Number of days to 30 creates a new code period beginning 30 days before the current date. If no action is taken on a new code issue after 30 days, this issue becomes part of the overall code. The default value is 30 days, 7 or 14 days are other common values. The maximum possible value is 90 days.

Specific analysis

Any changes made since that specific analysis are considered new code. 

This option gives you more control over your new code than the Number of days option. For example, for a project that follows a continuous delivery model, it allows you to mark the start of a new cycle, where a number of days would not be accurate enough.

With this option, the new code period's start date is the specific analysis date.

Reference branch

Any differences between your branch and a selected reference branch are considered new code.

SonarQube Server compares the current state of the analyzed branch with the current state of the reference branch. To do so, it uses SCM data obtained during analysis. 

The Reference branch option is useful for branch analysis before a pull request is created, or for short-lived branch analysis where pull requests are not in use (e.g. trunk-based developments). For the latest, the setting will also allow issues on the reference branch to inherit their status from your short-lived branch after its merge.

On the scanner side, it’s possible to use the sonar.newCode.referenceBranch property to apply the Reference branch option to the analysis of a branch, overriding the global new code definition set in the UI. See Analysis parameters for more information.

This setting is particularly useful during the first analysis when the branch to be analyzed does not exist yet in SonarQube Server. The sonar.newCode.referenceBranch property specifies the reference branch value.

For more information about issue management, see Issue management overview > issue synchronization between branches.

Recommended option depending on project type

Depending on the type of project you're working on, the best option to use will vary.  Here are general use cases for various types of projects:

Configuration levels

The new code definition can be set at the global, project and branch levels with the following restrictions:

• The Specific analysis option can only be set at the branch level. 
• Only the Previous version and Number of days options can be set at the global level.

The following applies:

• The branch-level definition has precedence over the project-level definition which has precedence over the global-level definition.
• The global-level definition is called baseline for new code:
  • It applies by default to all projects. A specific new code definition can be applied to the project instead.
  • If it applies to a project, the project consistently uses the baseline for new code. Consequently, any modifications to the baseline will automatically be applied to the project. 
  • The default baseline for new code is the Previous version option. 
• By default, any branch in a project applies the project’s new code definition. A specific new code definition can be applied to the branch instead.

Setting a new code definition

Global level 

Set a global new code definition at Administration > Configuration > General Settings > New Code. What you define as new code at the global level will be the default for your projects.

Project level

Set a new code definition for your project at Project Settings > New Code. If you're using an edition that supports multiple branches (starting in Developer Edition), what you define as new code at the project level will be the default for the project's branches.

Branch level

If you're using an edition that supports multiple branches (starting in Developer Edition) You can define new code for each branch:

1. Go to your project > Settings > New Code. 
2. In the branches table, define your new code option in the Actions column.

Both project and branch-specific new code definitions can be reset to use the default setting.

Three stages of SonarQube code review and analysis

1. The first base layer is code analysis in your SonarQube for IDE. This allows issues to be fixed as soon as they are introduced.
2. The pull request analysis layer ensures that all code to be merged is clean. 
3. The branch analysis layer guarantees that the main branch or another branch is ready for release or deployment.

Each layer has advantages in terms of speed and depth of analysis. We recommend implementing all three for the most comprehensive experience.

Related pages

• Setting a new code definition
• Quality profiles
• Quality gates