PLUGINAPI-201 Add new_ncloc (New Lines of Code) core metric

[christoph-sachse-sonarsource]

What

Adds a new core metric new_ncloc ("New Lines of Code") to CoreMetrics — the New Code period analog of ncloc.

Why

There is currently no "lines of code on new code" metric. As a stand-in, the UI often pairs new_lines against ncloc, but they don't measure the same thing:

• ncloc counts non-commenting lines of code (a line the analyzer considers code), so ncloc ≤ lines.
• new_lines counts all changed lines in the New Code period — code, comments, and blanks.

The result is the paradox that a project can report more new_lines than total ncloc. new_ncloc (changed lines that are also code lines) is the honest new-code counterpart of ncloc and lets the product stop overloading new_lines.

What's in this PR

Only the metric definition in CoreMetrics. This is the lowest-level, most-blocking change: the Compute Engine computation, Elasticsearch indexing, and web app all reference CoreMetrics.NEW_NCLOC_KEY, so nothing downstream compiles until this is released.

public static final String NEW_NCLOC_KEY = "new_ncloc";
public static final Metric<Integer> NEW_NCLOC = new Metric.Builder(NEW_NCLOC_KEY, "New Lines of Code", Metric.ValueType.INT)
  .setDescription("Non commenting lines of code on new code")
  .setDirection(Metric.DIRECTION_WORST)
  .setQualitative(false)
  .setDomain(DOMAIN_SIZE)
  .setDeleteHistoricalData(true)
  .create();

The attributes mirror NEW_LINES (and NCLOC): INT, DIRECTION_WORST, non-qualitative, DOMAIN_SIZE, deleteHistoricalData(true). As a size measure it intentionally has no bestValue/optimizedBestValue (consistent with ncloc/new_lines; setting optimizedBestValue would drop the measure on files with 0 new code lines, reintroducing the absent-vs-0 inconsistency this metric is meant to remove).

No DB migration is needed: metrics are auto-registered from CoreMetrics by reflection at server startup (RegisterMetrics).

Sequencing (this PR blocks the rest)

1. This PR → merge, then release sonar-plugin-api and bump pluginApiVersion in the consumers.
2. Compute new_ncloc in the Compute Engine — sonar-enterprise and sonarcloud-cleancode (NewSizeMeasuresStep: ncloc_data ∩ changed lines).
3. Index it for project search — ProjectMeasuresIndexerIterator in sonar-enterprise and sonarcloud-core.
4. Surface it in the web app — sonarcloud-webapp (MetricKey, l10n, Measures → Size domain).

Out of scope here and tracked separately: application/portfolio aggregation, ES range facet + project-search filtering, and the frontend rework that replaces new_lines where it stands in as the ncloc counterpart.

Validation

CoreMetricsTest passes; built locally against a JDK 11 toolchain.

Ticket: SONAR-26742

🤖 Generated with Claude Code

[hashicorp-vault-sonar-prod]

SONAR-26742

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[afloresescarcega]

Should an entry be added into CHANGELOG.md describing this new metric?

[afloresescarcega]

What are your thoughts on labelling these with @Beta? Same with the Metric below

Suggested change

	*/
	public static final String NEW_NCLOC_KEY = "new_ncloc";
	*/
	@Beta
	public static final String NEW_NCLOC_KEY = "new_ncloc";

[christoph-sachse-sonarsource]

Great question. It doesnt' look like it's been used in the past, so this would be a new approach. Codex says we should only add Beta if we think there's a chance we entirely remove this, which I don't see as plausible. If you know something I don't though, happy to add it.

[gitar-bot]

Code Review ✅ Approved

Adds the new_ncloc metric definition to CoreMetrics to enable accurate tracking of non-commenting lines of code on new code. No issues found.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[henryju]

Please move the ticket (or create a new one) in https://sonarsource.atlassian.net/browse/PLUGINAPI

[henryju]

Just FYI (and for fun), this metric was added briefly in SonarSource/sonarqube@062c27d#diff-3b3f405750ed6deeb27c749e4147f40043ac0b7d08915eefa822f4c9ed831a96 but quickly changed to new_lines in SonarSource/sonarqube@792d73d