> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/9.8/project-administration/defining-new-code.md).
# Defining New Code
Define what counts as new code in SonarQube Server 9.8 to apply consistent quality and security standards to the code you add or change.
{% hint style="info" %}
**For AI agents:** You're in the SonarQube Server 9.8 documentation. For a list of all 9.8 pages, see the [SonarQube Server 9.8 page index](https://739659627-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwuQmJTVPOsx7zNT5Aqwl%2Fuploads%2Fioqi91hBbUmj1DcpkxIJ%2Fsonarqube-server-9.8-llms.txt?alt=media). For the whole site, see the [page index](https://docs.sonarsource.com/llms.txt) or the [full text](https://docs.sonarsource.com/llms-full.txt). For another version, replace 9.8 in the URL with that version. The [latest version](https://docs.sonarsource.com/sonarqube-server/) has no version number in its URL.
{% endhint %}
Defining what is considered *new code* helps you apply consistent quality and security standards to the code you add or change. By focusing on code that’s been added or changed since your new code definition, you can set clear quality requirements and expectations. Your new code should meet those standards, and you’ll improve older code as you touch it. For more information on new code and why it’s important, check out [Quality standards and new code](/sonarqube-server/9.8/user-guide/clean-as-you-code.md).
## Setting your New Code definition
You can define new code at the global, project, or branch level.
* **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**. What you define as new code at the project level will be the default for the project’s branches if you’re using an edition that supports multiple branches (starting in [Developer Edition](https://www.sonarsource.com/plans-and-pricing/developer/)).
* **Branch level**: You can define new code for each branch from the **Actions** column of the branches table on the project’s **New Code** settings page if you’re using an edition that supports multiple branches (starting in [Developer Edition](https://www.sonarsource.com/plans-and-pricing/developer/)).
## New code definitions
You can define new code as changes from a previous version, a specific analysis, a reference branch, or within a specific period (number of days):
* **Previous Version**: Available at the global, project, and branch levels and works well for projects with regular versions or releases. Defines *new code* as any code that has changed code since the project’s most recent version. The current version of a project is determined in different ways depending on the build system being used:
* If the analysis is done using the [SonarScanner for Maven](/sonarqube-server/9.8/analyzing-source-code/scanners/sonarscanner-for-maven.md), then SonarQube Server reads the version from the `pom.xml` file.
* If the analysis is done with the [SonarScanner for Gradle](/sonarqube-server/9.8/analyzing-source-code/scanners/sonarscanner-for-gradle.md) then SonarQube Server reads the version from the `gradle.build` file.
* In all other cases, the version must be explicitly specified by setting the analysis parameter `sonar.projectVersion`.
* **Number of days**: Available at the global, project, and branch levels. Specify the number of days for a floating new code period. For example, setting the **Number of Days** to 30 creates a new code period beginning 30 days before the current date.
* **Specific analysis**: Available at the branch level starting in [Developer Edition](https://www.sonarsource.com/plans-and-pricing/developer/) and the project level for SonarQube Community Build. Choose a previous analysis as your new code definition. Any changes made since that analysis are considered New Code. Issues in new code are those that have appeared since a specific, defined version of the project. The version of a project is determined in the same way as for the *previous version* option, above. SonarQube Server defines the *start date of the new code period* as the date when the project was incremented to the specified version.
{% hint style="info" %}
Starting in [Developer Edition](https://www.sonarsource.com/plans-and-pricing/developer/), you can select any branch as the **Specific analysis** branch. In the SonarQube Community Build, past analyses are only available at the project level because the SonarQube Community Build doesn’t support multiple branches.
{% endhint %}
* **Reference Branch**: Available at the project and branch levels. Choose a specific branch to define your new code. Any changes made between your branch and the reference branch are considered New Code.\
You can also specify a reference branch using a scanner parameter, overriding the server’s definition. See the [Analysis parameters](/sonarqube-server/9.8/analyzing-source-code/analysis-parameters.md) page for more information about setting hierarchies and descriptions for various parameters.
When using any new code period type other than **Reference Branch**, we recommend completing your merges using the *fast-forward* option without a merge commit; examples include GitHub’s *squash and merge* or *rebase and merge* options. In this way, the blame for the merged commits will always have a more recent commit date.
## How the new code definition affects your analysis results
During analysis of the main branch, what counts as a *new code issue* is determined by the following:
1. SonarQube Server calculates the *start date of the new code period* based on the new code option chosen.
* In the case of the *previous version* option, this is the date when the project was first incremented to the version in question.
* In the case of the *number of days* option, it is the current date minus the specified number of days.
* In the case of the *specific analysis*, it is the date of the past analysis that you select in the history.
2. All lines of code in all files under analysis that have changed since the start date of the new code period are marked (and displayed in yellow in the SonarQube Server interface).
3. All issues with one or more of the marked lines as primary or secondary locations are categorized as *new code issues*.
{% hint style="info" %}
For analysis of pull requests and branches, the new code definition is not used. Instead, the *new code issues* are those introduced by the pull request or the branch itself. See [Pull request analysis](/sonarqube-server/9.8/analyzing-source-code/pull-request-analysis.md) and [Branch analysis](/sonarqube-server/9.8/analyzing-source-code/branches/branch-analysis.md) for more details.
{% endhint %}
The set of new code issues, in turn, affects many aspects of your results:
* The default [Quality gates](/sonarqube-server/9.8/user-guide/quality-gates.md) applies conditions only to new code issues.
* New code metrics are separated from overall code metrics in the main branch overview and the overviews of the other branches.
* The **Measures** panel separates new code data vs overall code data.
* The **Issues** page has a creation date facet where you can select to see only issues in *new code* or issues in *overall code*.
The activity graphs separate activity in the *new code* from activity in the *overall code*.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.sonarsource.com/sonarqube-server/9.8/project-administration/defining-new-code.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.