New Code, Clean-as-You-Code, Baselines, and Legacy Modernization: Configuration, Design Patterns, and Trade-Offs

1. The definition is an operating-model choice

No single New Code definition is universally correct. A release train, a trunk-based SaaS service, a regulated modernization program, and a feature-branch workflow have different reference points. The goal is not to choose the option that produces the fewest failures; it is to choose the option whose boundary matches the organization’s delivery semantics and can be explained later.

2. Decision table: match the baseline to the delivery model

3. Previous version: make release identity deliberate

Previous version works well when a version means something operational: a release, supported train, or milestone. Scanner CLI users should set sonar.projectVersion from an authoritative version source. Do not generate a new unique version for every CI build; that turns the baseline into a moving target.

Maven and Gradle can supply versions from build metadata. Whatever the source, retain the exact value in the analysis manifest. Changing the version is a release-governance event because it changes the start of the new-code period.

4. Number of days: predictable cadence, moving evidence

A time window is useful for continuous delivery when no release version provides a stable cycle boundary. The trade-off is that the population changes with the clock. Current Community Build documentation allows a maximum of 90 days and uses 30 days as the default example; 7 or 14 days are also common.

For audits and regression comparisons, always timestamp the observation. “New coverage was 92%” is incomplete if the 14-day window later becomes a different set of lines.

5. Specific analysis: precise but governance-heavy

Specific analysis is ideal for a controlled migration checkpoint because the reference can be tied to a concrete revision and analysis key. Its weakness is precisely that humans can move it. Current Community Build intentionally keeps this option out of the normal UI and directs administrators to the Web API, reducing the temptation to update it casually after every run.

6. Reference branch: comparison semantics and edition boundaries

Reference branch compares current code against another branch using SCM evidence. It is conceptually different from a time period. Full Git history and the correct reference matter because the scanner needs enough history to identify changed lines reliably.

Current Community Build’s feature matrix must be checked carefully: Community Build is intentionally narrower than commercial SonarQube Server for branch analysis, while pull-request capabilities have their own restrictions. Do not teach a Server-only branch topology as a mandatory Community Build lab. When the feature is unavailable, model it with a two-branch local Git diff and document the intended SonarQube setting as a simulation.

7. Clean-as-You-Code versus big-bang remediation

A mature program often uses a new-code gate as the default release control plus a legacy-risk backlog with severity-based SLAs, remediation campaigns, and trend metrics. That separates “do not add debt” from “reduce inherited debt” without confusing either objective.

8. Global baseline versus project-specific policy

Community Build’s global New Code baseline applies by default. A project-specific definition overrides it. That means a global administrator can improve consistency, while project administrators still need a documented reason for exceptions.

9. Baseline-change control template

New Code policy change record
Project:
Current definition / value:
Proposed definition / value:
Current project revision and last analysis key:
Reason tied to delivery model (not gate result):
Expected effect on new-code population:
Legacy-risk impact:
Affected quality-gate conditions:
SCM / branch / version prerequisites:
Edition prerequisites:
Approver / owner:
Verification plan:
Rollback definition / value:
Review or expiry date:

If the record cannot explain why the policy matches the delivery model independent of today’s pass/fail result, the change is not ready.

10. Worked selection scenario

Scenario: a 12-year service deploys several times per day, has no release-version boundary, and carries a known low-coverage legacy layer. The team wants new work to meet high coverage while keeping the legacy backlog visible.

Choice: a governed Number-of-days baseline can match the delivery cadence better than Previous version. Pair it with the Sonar way new-code gate and a separate legacy backlog. Record the window length, full SCM checkout, gate conditions, and owner. Reject the proposal to set the window to one day only after a failing analysis unless that one-day cadence was already the approved policy.

Knowledge check

Official references and version notes

• Quality standards and new code — current New Code concepts, four definition modes, default baseline, and Clean-as-You-Code framing.
• Configuring new code calculation — project overrides, Specific analysis API-only behavior, and Previous version configuration.
• Global New Code baseline — global inheritance and the default Previous version baseline.
• Checked-out code — full Git history requirements for New Code, blame, and issue backdating.
• Issue management solution — issue identity/date/backdating and how current analysis relates findings to new code.
• Understanding quality gates — Sonar way and new-code-focused quality conditions.
• Feature comparison table — current Community Build versus Server/Cloud branch and pull-request boundaries.
• Analysis overview — scanner/report/Compute Engine processing and new/overall result computation.
• Web API — authenticated API usage and release-sensitive endpoint guidance.
• SonarQube downloads — current Community Build release identity.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used by the local lab.