# Improving code quality

## What is this approach? <a href="#what-is-this-approach" id="what-is-this-approach"></a>

Improving code quality as you code is an approach that eliminates many of the challenges that come with traditional methodologies. As a developer, you focus on maintaining high standards and taking responsibility specifically in the [defining-new-code](https://docs.sonarsource.com/sonarqube-server/10.4/project-administration/clean-as-you-code-settings/defining-new-code "mention") you're working on. SonarQube gives you the tools to set high standards and take pride in knowing that your code meets those standards.

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

With this approach, your focus is always on [defining-new-code](https://docs.sonarsource.com/sonarqube-server/10.4/project-administration/clean-as-you-code-settings/defining-new-code "mention") (code that has been added or changed according to your new code definition) and making sure the code you write today is maintainable and safe.

The [defining-new-code](https://docs.sonarsource.com/sonarqube-server/10.4/project-administration/clean-as-you-code-settings/defining-new-code "mention") 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](https://docs.sonarsource.com/sonarqube-server/10.4/project-administration/clean-as-you-code-settings/defining-new-code "mention").

## Understanding the benefits <a href="#understanding-the-benefits" id="understanding-the-benefits"></a>

To get a visual representation of the benefits based on the data in your projects, navigate to **More** > **Clean as You Code** in SonarQube.

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

With this approach, you aren't responsible for anyone else's code. You own the quality and security of the new code you are working on today. If you add new issues, SonarQube 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](https://docs.sonarsource.com/sonarqube-server/10.4/user-guide/issues "mention") page.

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

Your [quality-gates](https://docs.sonarsource.com/sonarqube-server/10.4/user-guide/quality-gates "mention") is a set of conditions that tells you whether or not your project is ready for release. With this approach, 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 will be delivered with production-ready code quality. 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 clean up 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](https://docs.sonarsource.com/sonarqube-server/10.4/user-guide/quality-gates "mention") page.

### What conditions are required for your quality gate? <a href="#what-conditions-are-required-for-your-quality-gate" id="what-conditions-are-required-for-your-quality-gate"></a>

We recommend configuring all your quality gates to improve code quality as you write. You can do this by configuring your quality gate conditions for new code. This helps you ensure that you're not introducing issues in your code.

A quality gate is configured for improving code quality as you write when it has the following conditions on new code:

* No issues are introduced (the quality gate fails when the **Number of issues** is higher than 0)

OR

* **Reliability Rating** is not worse than A
* **Security Rating** is not worse than A
* **Maintainability Rating** is not worse than A

In addition, it ensures that:

* **Security Hotspots Reviewed** is not less than 100%, meaning that all the security hotspots are reviewed.
* \[Configurable] There is a limited amount of **Duplicated Lines**.
* \[Configurable] **Coverage** of code by tests is sufficient.

The duplication and test coverage conditions are configurable to your specifications. The other conditions are locked and cannot be edited if you wish to remain compliant with this approach.

To ensure that your new code is always production-ready, we recommend including the "No new issues are introduced" condition in your quality gate. You can do this by clicking the **Review and Optimize Quality Gate** button if your quality gate is already compliant, or the **Review and Fix Quality Gate** button if your quality gate is not compliant.

For more information, see [quality-gates](https://docs.sonarsource.com/sonarqube-server/10.4/user-guide/quality-gates "mention").

{% hint style="info" %}
With this approach, you should always focus on new code, so we do not recommend adding conditions for overall code to your quality gate.
{% 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 UI. You can then decorate your pull requests with SonarQube 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](https://docs.sonarsource.com/sonarqube-server/10.4/analyzing-source-code/pull-request-analysis "mention").

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

This quality gate is designed to achieve production-ready increments of code 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, making it hard for developers to take ownership of their own code as they have to worry about older code.

## Frequently asked questions (FAQ) <a href="#frequently-asked-questions" id="frequently-asked-questions"></a>

### General <a href="#general" id="general"></a>

**What is this approach to code quality?**

This software development practice requires each addition or modification of code to comply with code quality standards. By always committing maintainable code, you incrementally improve the quality of your code base.

**I currently run dedicated sprints to address technical debt. What are the drawbacks of this approach?**

* The team needs to plan dedicated time for such sprints, delaying new feature development.
* As debt-addressing sprints don't happen frequently enough, team is slowed down by the debt introduced during recent feature sprints.
* Developers are fixing old issues introduced by someone else. The ownership is low and complexity to fix is high.
* Such sprints are often a burden for developers lowering their morale.
* Developers are not motivated to deliver maintainable code outside of such debt-addressing sprints

**Which issues are prioritized in this methodology? Why?**

With this methodology, you focus on issues in the code you wrote or changed recently (we call it *new code*). Those issues are easy to fix as the context is fresh in memory and it's appealing to deliver the feature with no bugs.

Note that when changing existing code, some old issues might pop up. Those are prioritized too, as that way you incrementally with little hassle improve the whole code base.

**How to define the quality standard?**

With a quality profile, you can choose which rules should be enforced in your team/organization. Coverage and duplication thresholds can be set with a quality gate. Together, these comprise the quality standard.

**Is this approach enough in all scenarios?**

In some cases, you would need additional measures, e.g. to ensure the quality of the overall code base or to perform refactoring. Improving code quality as you write does not hinder you from pursuing these additional use cases.

**The quality of the overall code is important to us. What should we do?**

By practicing this approach, you are ultimately improving your overall code quality. With this approach, you will also improve parts of the old code you are changing. Thus improving the overall code health over time.

Along with that, you can enable quality gate conditions on the overall code to enforce some overall quality standards.

### Setting up <a href="#setting-up" id="setting-up"></a>

**How to set up my project and processes?**

* * Set up a [defining-new-code](https://docs.sonarsource.com/sonarqube-server/10.4/project-administration/clean-as-you-code-settings/defining-new-code "mention") for your project (e.g. previous version)
  * Use [quality-gates](https://docs.sonarsource.com/sonarqube-server/10.4/user-guide/quality-gates "mention") configured for improving code quality as you write
  * Set up your CI to run frequent branch scans (daily or on every commit)
  * Set up pull request scan through DevOps integration (when available)
  * Install and use [SonarLint](https://app.gitbook.com/o/2ibCvzwZt86Nlk2zloB7/s/6LPRABg3ubAJhpfR5K0Y/) in your IDE

**How can I make the transition smooth?**

* * Start at the beginning of a release cycle, so that you start with no issues in the new code.
  * Try to fix issues in new code as soon as possible.
  * Ensure frequent scans of the project, so that your quality gate status is up to date.

**What is new code? How to define new code?**

This methodology suggests focusing on recent code changes, this is called *new code*. This includes both added code and changed code.

New code can be [defining-new-code](https://docs.sonarsource.com/sonarqube-server/10.4/project-administration/clean-as-you-code-settings/defining-new-code "mention"). The most common options are:

* based on the project's releases: all unreleased code is considered recent
* based on a number of days: all code not older than X days is considered recent.

For pull requests, all new or changed lines are considered new code.

**Which quality gate and quality profile should I use?**

The best way to start is to rely on the built-in 'Sonar way' quality gate and built-in 'Sonar way' quality profiles (there is one for each language). You can always create custom ones if you need additional quality gate conditions or more/other rules activated.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sonarsource.com/sonarqube-server/10.4/user-guide/clean-as-you-code.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.