# Configuring new code calculation

By default, your project applies the baseline for new code (global-level new code definition). This means it consistently uses the baseline for new code. Consequently, any modifications to the baseline will automatically be applied to your project. You can apply a specific new code definition for your project instead.

For more information, see [about-new-code](https://docs.sonarsource.com/sonarqube-community-build/user-guide/about-new-code "mention").

## Setting a specific new code definition for your project <a href="#setting-specific-new-code-definition-for-project" id="setting-specific-new-code-definition-for-project"></a>

As a project administrator, you can set the new code definition for your project in the UI (except the Specific analysis option) or using the Web API, at creation time or anytime later as explained below.

{% hint style="info" %}
For more compliance with the Clean as You Code methodology, the Specific analysis option can only be set using the Web API, as it would require frequent user action to be kept up to date.
{% endhint %}

### In the UI <a href="#in-the-ui" id="in-the-ui"></a>

To set a specific new code definition for your project in the UI:

1. Retrieve your project. See [retrieving-projects](https://docs.sonarsource.com/sonarqube-community-build/user-guide/viewing-projects/retrieving-projects "mention") for more details.
2. Go to **Project Settings > New Code**.
3. In **Choose the baseline for new code for this project**, select **Define a specific setting for this project** and then the option you want to apply to your project.

### Via the Web API <a href="#via-the-web-api" id="via-the-web-api"></a>

Use the [api/new\_code\_periods/set](https://next.sonarqube.com/sonarqube/web_api/api/new_code_periods/set) endpoint.

## Additional setup and recommendations <a href="#additional-setup-and-recommendations" id="additional-setup-and-recommendations"></a>

Make sure to follow the recommendations about the [verifying-code-checkout-step](https://docs.sonarsource.com/sonarqube-community-build/analyzing-source-code/scanners/scanner-environment/verifying-code-checkout-step "mention") and [scm-integration](https://docs.sonarsource.com/sonarqube-community-build/analyzing-source-code/scm-integration "mention").

We also 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. That way, blame for merged commits will always have a more recent commit date.

### If using Previous version option <a href="#if-using-previous-version-option" id="if-using-previous-version-option"></a>

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](https://docs.sonarsource.com/sonarqube-community-build/analyzing-source-code/scanners/sonarscanner-for-maven "mention"), then SonarQube Community Build reads the version from the `pom.xml` file.
* If the analysis is done with the [sonarscanner-for-gradle](https://docs.sonarsource.com/sonarqube-community-build/analyzing-source-code/scanners/sonarscanner-for-gradle "mention") then SonarQube Community Build reads the version from the `build.gradle` file.
* In all other cases, you must explicitly specify the version by setting the analysis parameter `sonar.projectVersion`.

## Related pages <a href="#related-pages" id="related-pages"></a>

* [about-new-code](https://docs.sonarsource.com/sonarqube-community-build/user-guide/about-new-code "mention")
* [setting-new-code-definition-at-global-level](https://docs.sonarsource.com/sonarqube-community-build/instance-administration/analysis-functions/setting-new-code-definition-at-global-level "mention")