Sample report · synthetic data

From scan signal to a change you can make.

This walkthrough shows how a DebtDrone report can help a team review structural findings and choose a next step. The repository, paths, and values below are invented for illustration. This is not a live scan or a customer report.

Scan your own repository Explore findings

Scan context

Fictional “Parcel Queue” TypeScript service · illustrative full-repository snapshot · three open complexity findings shown. The fixed severity boundaries below come from the scanner; none of the values were measured from a real repository.

LanguageTypeScript

Findings shown3

Illustrative effort threshold15

The report

Findings you can act on

Severity points you toward review order. The measured signal starts the conversation; the rationale and next step tell you what to inspect before editing.

01▪ critical

Split a branching checkout handler

src/checkout/submitOrder.ts · line 42

Cyclomatic complexity 24 · high >15 · critical >20

Why it matters

Payment, inventory, and retry decisions share one function. A small change to one branch can affect another, and each new condition increases the paths a reviewer must reason about.

Suggested next step

Extract the payment and inventory decisions into named functions, then add tests for declined payment, out-of-stock items, and retry behavior before moving the branches.

02▪ critical

Untangle nested delivery rules

src/shipping/quoteDelivery.ts · line 18

Nesting depth 6 · high >4 · critical >5

Why it matters

Region, carrier, and package exceptions are nested together. The resulting path is hard to follow when a new carrier rule is added.

Suggested next step

Use guard clauses for unsupported regions and packages, then isolate carrier selection behind a small function with table-driven examples.

03▴ high

Separate audit event decisions

src/audit/writeEntry.ts · line 11

Cognitive complexity 22 · high >20 · critical >25

Why it matters

Several nested conditions decide which audit fields to emit. The flow is difficult to follow even though each branch is individually short.

Suggested next step

Name the event-specific decisions, test the emitted fields for each event type, and then flatten the conditionals.

How to read effort estimates

In a real report, a complexity finding’s estimated debt is calculated from the amount above the configured cyclomatic-complexity threshold, multiplied by a fixed cost per point. At or below the threshold, that complexity estimate is zero. Treat the result as a prioritization aid, then confirm the work with an engineer who knows the code.

This synthetic example omits hour totals, trend deltas, and money saved: none was measured. A lower issue count does not by itself prove faster delivery or cost savings.

See what your own code reveals.

Connect a repository to get a report based on your code, then review each finding with the people who maintain it.

Start free with GitHub