> 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/10.7/core-concepts/clean-as-you-code/about-new-code.md).
# About new code
Conceptual information about new code and how it is defined in SonarQube Server 10.7.
{% hint style="info" %}
**For AI agents:** You're in the SonarQube Server 10.7 documentation. For a list of all 10.7 pages, see the [SonarQube Server 10.7 page index](https://3272878703-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FI10pmJWeVVXYITlQJllp%2Fuploads%2FnEeIaIlHm7ezec5g9iHc%2Fsonarqube-server-10.7-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 10.7 in the URL with that version. The [latest version](https://docs.sonarsource.com/sonarqube-server/) has no version number in its URL.
{% endhint %}
New code is code that you’ve recently added or modified. To ensure you focus your efforts on the right lines of code, Sonar will highlight technical debt (issues, code coverage, etc) in the new code.
In pull requests, all code changes are considered new code. For branch and IDE, the *new code definition* setting tells Sonar which part of the code is considered new.
## Your new code definition
Each project in the Sonar solution has a *new code definition*. It’s a setting that determines what code in your projects is considered new code.
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:
## New code definition options
**Previous version**
Defines new code as any code that has changed since the most recent version increment of the project.
**Number of days**
Defines new code as any code that has changed in the last X days.
**Specific analysis**
Defines new code as any changes made since that specific analysis.
This option gives you more control over your new code than the "Number of days" option. For example, for 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.
**Reference branch**
Any differences between your branch and a selected reference branch are considered new code.
## New code period vs. branch comparison
* For the previous version, number of days, and specific analysis options, 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. Here is how the start date is calculated: \*
* **Previous version**: Date when the project was first incremented to the version in question.
* **Number of days**: Current date minus the specified number of days.
* **Specific analysis**: Date of the past analysis.
* For the reference branch option, the analyzed branch is compared to the current state of the reference branch based on [SCM integration](/sonarqube-server/10.7/analyzing-source-code/scm-integration.md). If the SCM is not available, the two branches are compared based on their current state in SonarQube Server.
All lines of code in all files under analysis that are not in the reference branch or have changed since the start date of the new code period are marked. In SonarQube Server, these lines are displayed in yellow.
See also [Issue management solution](/sonarqube-server/10.7/user-guide/issues/solution-overview.md) to learn how new issues are calculated.
## Focus on new code in the UI
In the Sonar solution, all views that display found issues or other code metrics always prioritize the status of new code. Data on overall code is available but is not displayed by default. This encourages you to maintain focus on the new code.
The set of new code issues, in turn, affects many aspects of your results:
* The default [Quality gates](/sonarqube-server/10.7/instance-administration/analysis-functions/quality-gates.md) applies conditions only to new code issues.
* In SonarQube Server and Sonarcloud:
* There are separate tabs for new code data vs. overall code data.
* Selecting the **Issues in new code** filter found on *your project* > **Issues** allows you to quickly switch between issues in new code or issues in overall code.
* The activity graphs separate activity in the new code from activity in the overall code.
## Next steps
In SonarQube Server, the new code definition can be set at different levels (global, project, and, starting in [Developer Edition](https://www.sonarsource.com/plans-and-pricing/developer/), at the branch level).
To learn how to configure these options, see "Setting a new code definition" in the [Setting up improving code quality](/sonarqube-server/10.7/project-administration/setting-up-clean-as-you-code.md).
## Related pages
* [Setting up improving code quality](/sonarqube-server/10.7/project-administration/setting-up-clean-as-you-code.md)
---
# 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/10.7/core-concepts/clean-as-you-code/about-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.