Clean as You Code
SonarCloud is designed to ensure high code quality and security by helping you, the developer, make sure that every code change that you commit to your project is free of issues. By always committing clean code, you incrementally improve the overall quality of your project. We call this methodology Clean as You 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 security issues. You can then address these issues right away and ensure that all new code added to the project is always clean.
The traditional approach to code quality usually emphasizes a separate stage of review at the end of each development cycle where quality issues are found and addressed. Having a separate stage in the process, often conducted by a different team, can lead to problems because the amount of technical debt accumulated can become unmanageable and the splitting of responsibility means quality issues can fall through the cracks.
Clean as You Code avoids these pitfalls. It clarifies that code quality and code security are the responsibility of you as the developer. It also keeps the maintaining of code quality manageable by making it part of the daily cadence of your work.
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.
If you have an existing project and start using SonarCloud with it, you may find that initially, SonarCloud finds a lot of quality issues in your existing, old, code. At first, you might think that you need to start remediating this technical debt immediately. In fact, it is still better to follow the Clean as You Code approach and focus on new code.
It turns out that 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. This approach is a lot more sustainable because it is part of your everyday work and does not require a separate, special effort of remediation. An effort which, experience shows, is often delayed indefinitely.
By encouraging this focus on new code, SonarCloud helps 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.
SonarCloud helps you focus on new code by building the concept right into the product.
We recommend that you use the SonarLint IDE extension together with SonarCloud. It works like a spell-checker to provide in-IDE code analysis, alerting you to problems before you even commit any code. This provides the first level of defense to keep the code that you ultimately merge into your main branch clean.
Code changes made as part of a pull request are always considered new code. A major emphasis is placed on identifying such issues and surfacing them to the developer, not just through the SonarCloud interface itself but also through the pull request decoration in the interface of your code repository platform (GitHub, etc.), where you are most likely to notice them. In this way, SonarCloud encourages the fixing of code quality and security issues even before the code is merged into the main branch of the project.
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.
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.
SonarCloud has a feature called quality gates. A quality gate is an indicator of code quality that can be configured to give a go/no-go signal on the current release-worthiness of the code. This also provides immediate feedback to you and your team about the global quality of the codebase.
Quality gate settings always distinguish conditions that apply to new code from conditions that apply to overall code and by default only conditions on new code are applied. This allows release decisions to be made specifically based on new code status.
For more information on how to configure a quality gate for Clean as You Code, see Managing quality gates.
The traditional approach to code quality suffers from an ownership problem. Responsibility for code quality is often split. A separate QA team identifies the issues late in the process and then attempts to get the original developers to return their attention to the problematic code and address the issues. In contrast, the Clean as You Code methodology places the ownership of code quality squarely with the individual developer who wrote the code in the first place. We believe that only you and your fellow developers can have a sustainable impact on code quality and security.
SonarCloud identifies issues as soon as possible in the development cycle, sometimes before the code is even committed (if you are using SonarLint), often at the pull requests stage and at the latest in recently merged new code.
SonarCloud also uses repository information to tag each issue with the name of the developer who last touched that line of code.
This makes it easy to identify who is responsible for which issues. Check out the Issues page documentation for more details.
Further, SonarCloud makes it easy for you to address each issue by providing detailed guidance on the details of each issue and how to remedy it. Developers have reported that as they use SonarCloud the educational aspect of the tool becomes more and more evident. This leads to a virtuous cycle where code quality increases as a developer's skills and knowledge increase.
Together, the quickness and clarity of the feedback, the definitive assignment of responsibility, and the assistance given by the system make it easy for developers to find and fix issues and that helps make the process an integral part of their daily work.
What is ‘Clean as You Code’ (CaYC)?
The Clean as You Code methodology is a software development practice that requires each addition or modification of code to comply with code quality standards. By always committing clean 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 clean code outside of such debt-addressing sprints
Which issues are prioritized in the Clean as You Code methodology? Why?
With the Clean as you Code 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 clean the whole code base.
How is Clean as You Code different from Clean Code?
Clean Code refers to the state of a code base. Clean as You code is the methodology that helps developers reach the Clean Code state most efficiently.
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 Clean as You Code 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. Clean as You Code 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 CaYC, you are ultimately improving your overall code quality. With CaYC, you will also clean parts of the old code you are changing. Thus cleaning the overall code over time.
Along with that, you can enable quality gate conditions on the overall code to enforce some overall quality standards.
How to set up my project and processes to practice CaYC?
How can I make the transition to CaYC practice smooth?
- Start practicing CaYC 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?
The Clean as you code methodology suggests focusing on recent code changes, this is called new code. This includes both added code and changed code.
New code can be defined to suit your development context. 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.