> 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.0/user-guide/clean-as-you-code.md).

# Quality standards and new code

Improve code quality by focusing on new code and applying consistent quality standards. This page is for SonarQube Server 10.0.

{% hint style="info" %}
**For AI agents:** You're in the SonarQube Server 10.0 documentation. For a list of all 10.0 pages, see the [SonarQube Server 10.0 page index](https://1407932334-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5RUfx2eNg633cL6XgYzZ%2Fuploads%2FMKuy2QelfTxXM57mBiay%2Fsonarqube-server-10.0-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.0 in the URL with that version. The [latest version](https://docs.sonarsource.com/sonarqube-server/) has no version number in its URL.
{% endhint %}

## Defining a quality standard <a href="#defining-a-quality-standard" id="defining-a-quality-standard"></a>

SonarQube Server helps you improve code quality as you write by focusing on new code and applying consistent quality standards. As a developer, you focus on maintaining high standards for the code you add or change. SonarQube Server gives you the tools to enforce those standards and take pride in shipping maintainable and secure code.

## Focus on new code <a href="#focus-on-new-code" id="focus-on-new-code"></a>

By focusing on [Defining New Code](/sonarqube-server/10.0/project-administration/defining-new-code.md) (code that has been added or changed according to your new code definition), you can make sure the code you write today is maintainable and secure.

The [Defining New Code](/sonarqube-server/10.0/project-administration/defining-new-code.md) 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). Depending on the level at which your new code definition is set, you can change the starting point to fit your situation.

For more information on setting your new code definition, check out [Defining New Code](/sonarqube-server/10.0/project-administration/defining-new-code.md).

## Personal responsibility <a href="#personal-responsibility" id="personal-responsibility"></a>

By focusing on new code, you aren’t responsible for anyone else’s code. You own the quality and security of the code you are working on today. If you add new issues, SonarQube Server automatically assigns them to you so you can maintain the quality of your code.

For more information on issues and how they are assigned, check out the [Issues](/sonarqube-server/10.0/user-guide/issues.md) page.

## Quality gate <a href="#quality-gate" id="quality-gate"></a>

Your [Quality gates](/sonarqube-server/10.0/user-guide/quality-gates.md) is a set of conditions that tells you whether or not your project is ready for release. To support improving code quality as you write, your quality gate should:

* **Focus on New code metrics** – When your quality gate is set to focus on new code metrics (like the built-in Sonar way quality gate), new features can be delivered with high code quality and security. As long as your quality gate is green, your releases will continue to improve.
* **Set and enforce high standards** – When standards are set and enforced on new code, you aren’t worried about having to meet those standards in old code and having to remediate someone else’s code. You can take pride in meeting high standards in *your* code. If a project doesn’t meet these high standards, it won’t pass the quality gate, and is therefore not ready to be released.
* **Be a reliable measure of code quality** - When you consistently have a passing quality gate, you have a clear indication that developers can maintain high standards on all new code.

For more information on quality gates and to make sure your quality gate is enforcing your standards, check out the [Quality gates](/sonarqube-server/10.0/user-guide/quality-gates.md) page.

### What does a quality gate focused on new code require? <a href="#what-does-a-quality-gate-focused-on-new-code-require" id="what-does-a-quality-gate-focused-on-new-code-require"></a>

A quality gate focused on new code helps you keep code quality and security high while changes are still easy to review and fix.

* No new bugs are introduced
* No new vulnerabilities are introduced
* All new security hotspots are reviewed
* New code has limited technical debt
* New code has limited duplication
* New code is properly covered by tests

For more information see [Quality gates](/sonarqube-server/10.0/user-guide/quality-gates.md).

{% hint style="info" %}
When your quality gate is focused on new code, we do not recommend adding conditions for overall code.
{% endhint %}

## Pull request analysis <a href="#pull-request-analysis" id="pull-request-analysis"></a>

You can use pull request analysis and pull request decoration to make sure that your code meets your standards before merging. Pull request analysis lets you see your pull request’s quality gate in the SonarQube Server UI. You can then decorate your pull requests with SonarQube Server issues directly in your DevOps platform’s interface.

For more information on setting up pull request analysis and pull request decoration, see the documentation on [Pull request analysis](/sonarqube-server/10.0/analyzing-source-code/pull-request-analysis.md).

## Potential drawbacks of stricter quality gates <a href="#potential-drawbacks" id="potential-drawbacks"></a>

A quality gate focused on new code is designed to keep each change maintainable and secure with the least amount of friction in the development process. Adding more conditions may lead to bottlenecks in the pace of development with minimal benefit. You also run the risk of an ignored quality gate because frequent failures may cause a debate on which conditions to prioritize.

It is also important to note that adding conditions on overall code will shift your focus away from new code to old code. This makes it harder for developers to take ownership of their own code because they also have to worry about older 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/10.0/user-guide/clean-as-you-code.md?ask=<question>&goal=<user_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.