Clean as You Codefleeting
- External reference: https://sonarcloud.io/documentation/improving/clean-as-you-code/
- External reference: https://docs.sonarqube.org/latest/user-guide/clean-as-you-code/
A concept of sonarqube that you should focus on what you break in your changes instead of seeing it in all the noise of the technical debt. It tries to show you errors as fast as possible so that you clean then on the fly instead of relying on a error prone and hard to maintain “develop then QA” workflow.
They assume that with time, you will eventually go through all the code and clean the technical debt that way.
This idea of keeping the code clean is likely why there is no measure of errors fixed. You can see, in your new code how much errors are in there, but never how much errors you fixed. It totally makes sense with the idea of clean as you code, for you only focus on committing code without errors.
Also, this helps keeping a low cognitive load, because you only focus on your changes (except for the impact on the rest of the file) and how it does not make the code base worse. You can totally ignore the technical debt.
With Clean as You Code, your focus is always on New Code (code that has been added or changed according to your New Code definition) and making sure the code you write today is clean and safe.
With Clean as You Code, 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 quality in your code
The core idea of clean as you code is that you focus your attention and effort on new code. As you work on features and improvements, SonarCloud analyzes your code on each new commit and alerts you to any code quality problems and vulnerabilities.
If you adopt Clean As You Code from the start of a project, you should never face the problem of having to remediate problems in old code; SonarCloud makes sure that the code is clean with each commit.
in any software project a certain percentage of old code is touched with each new feature and improvement added. When this happens in a project analyzed by SonarCloud, issues in that old code will be highlighted and fixed as part of the normal evolution of the code.
Eventually, the entire codebase will be cleaned up without you ever having to explicitly go back and dig through the old code.
does not require a separate, special effort of remediation. An effort which, experience shows, is often delayed indefinitely.
avoid the traditional pitfall where addressing code quality at the end of the development process results in an overwhelming number of issues that can be difficult to address. Instead with SonarCloud code quality becomes part of the normal, incremental development process.
- New code definition
- Apart from pull requests (where all code changes are considered new code) SonarCloud also encourages you to specify a new code definition for other contexts within their project. The details of this definition depend on your project, but the aim is to encompass code changes that are part of the current phase in development. For example, for projects that have explicit versioning of releases, the new code definition can be set as “everything that has changed since the last version bump”. Alternatively, for projects that work on the principle of continuous delivery (i.e., they have no versions) other criteria are available to define new code.
Notes linking here
- bootstrapping sonar on a project
- defining what “projectVersion” means
- is it ok to let the CI fail and not do anything about it?
- is tdd possible in companies?