Crap Score

CRAP Score Analysis

Calculate CRAP (Change Risk Anti-Patterns) scores for .NET methods to identify code that is both complex and undertested.

Background

The CRAP score combines cyclomatic complexity and code coverage into a single metric:

$$\text{CRAP}(m) = \text{comp}(m)^2 \times (1 - \text{cov}(m))^3 + \text{comp}(m)$$

Where:

• $\text{comp}(m)$ = cyclomatic complexity of method $m$
• $\text{cov}(m)$ = code coverage ratio (0.0 to 1.0) of method $m$

A method with 100% coverage has CRAP = complexity (the minimum). A method with 0% coverage has CRAP = complexity^2 + complexity.

When to Use

• User wants to assess which methods are risky due to low coverage and high complexity
• User asks for CRAP score of specific methods, classes, or files
• User wants to prioritize what to test next within a named method, class, or file based on coverage-and-complexity risk
• User wants to evaluate test quality beyond simple coverage percentages

When Not to Use

• User just wants to run tests (use run-tests skill)
• User wants to write new tests (use code-testing-agent)
• User only wants a coverage percentage without complexity analysis
• User wants project-wide coverage/CRAP analysis or priorities (use coverage-analysis)

Inputs

Workflow

Step 1: Collect code coverage data

If the user supplies a valid Cobertura report that contains the requested target, use it directly and do not rerun tests. If the supplied report is malformed, empty, internally contradictory, or missing the target, treat it as failed input: regenerate it with a repository-compatible command when possible, or request a valid report when collection is unavailable. Otherwise invoke run-tests to classify the repository's test platform and confirm the compatible command shape, then require a command that emits Cobertura:

Use an equivalent repository-owned command when the project defines one. Search the results directory recursively when the collector creates a GUID subfolder. Do not substitute a generic binary .coverage command when no converter is available.

Do not stop at the first restore, compilation, test, or collector failure. Classify the failing layer, inspect every report the command emitted, and exhaust non-persistent retries before asking for input. Safe retries include command-line MSBuild properties that leave source and manifests unchanged and an already-installed or repository-provided alternative collector. A trivial source error is a collection blocker, not the final analysis, when a reversible command-line setting can compile the same source. Never call an empty Cobertura file a successful fallback.

For classic non-SDK projects (ToolsVersion, explicit compile items, or packages.config), use only a repository-provided coverage command that emits Cobertura. If none exists, request Cobertura XML and stop; do not migrate the project or inject an SDK-style provider. CRAP scores always require real coverage data.

Never estimate coverage

Guessed coverage produces wrong CRAP scores, which is worse than no answer. For a classic project with no repository coverage command or existing report, stop here and request Cobertura.

Do not add coverage packages, change project manifests, or install global tools unless the user explicitly authorized dependency/tooling changes. If the repository lacks a usable provider or converter, report that exact prerequisite and the compatible command shape identified through run-tests, then stop. If an existing binary .coverage report is present, convert it only with an already-installed or repository-provided converter; otherwise request authorization or a Cobertura export. If tests execute with failures but still emit valid coverage, continue with that data and note the failures. Report complexity on its own if useful, but never publish a CRAP number derived from assumed coverage.

Before using a report, verify that it parses, contains at least one class and method, and contains the requested target. An empty report or a report that omits the target is failed collection or filtering, not 0% coverage. Regenerate coverage when possible; otherwise stop without publishing a CRAP score.

If the user supplies an existing report, state that it was not regenerated. Do not describe its data as current unless its provenance is established by running the repository's coverage command in this analysis.

Step 2: Compute cyclomatic complexity

Prefer a machine-produced per-method complexity from a repository-provided code metrics report or from the Cobertura method's complexity attribute when that report maps to the current source. Microsoft.CodeAnalysis.Metrics can generate method-level CyclomaticComplexity data through msbuild /t:Metrics, but do not add the package or modify the project without user approval.

If no machine-produced metric exists, analyze the current target source and label the result as a manual complexity count. Count the following decision points (each adds 1 to the base complexity of 1):

Base complexity is 1 for every method. Each decision point adds 1.

When counting manually, read the source file, report the construct-by-construct breakdown, and do not use a source comment as evidence. Count every occurrence, including operators nested inside arguments or return expressions; before declaring a conflict, rescan specifically for &&, ||, ??, ?., ternaries, and switch/pattern arms. If a supplied report maps to the current method and a careful recount agrees, use its metric decisively. If a genuine disagreement remains, label both sources; when the user explicitly asked to use that report, calculate the primary CRAP result from its machine-produced metric and present the manual count as a caveat rather than withholding the requested result.