Deslop 0.35.0: Accuracy in Duplicate Code Detection

A duplicate code detector earns its place in code review by finding copies worth inspecting. False positives waste review time. False negatives leave the same bug waiting to be fixed in another location. Incomplete findings can identify a copy while hiding most of it.

Deslop 0.35.0 addresses these problems through clone classification, complete-range recovery and clearer comparison evidence. Download the release.

Find the whole copy

One defect could split a long, exact copy into short overlapping findings. Recognizing that two files share code was insufficient: a reviewer needed the complete copied range.

The range recovery change joins overlapping exact findings when the complete source ranges match byte for byte and form valid consecutive syntax-tree siblings. If a valid join is impossible, copied windows must remain visible instead of being discarded. Its CLI test checks the entire copied text, both file paths, exactly two occurrences, the category and the rank.

Other recall changes recover copied setup inside edited methods and copies within one file. The boundaries matter: reporting shared setup must not drag unrelated neighbouring methods into the finding.

Separate renamed copies from unrelated lookalikes

Renaming variables or changing test messages does not necessarily change the work being copied. Those cases belong under Nearly identical code, alongside small edits. Larger edits with substantial copied work belong under Similar code.

Matching layout alone is weaker evidence. Same shape, different content is informational and contributes nothing to clone counts, duplicated mass or duplication percentages. A repeated control-flow skeleton is not enough to declare technical debt.

The content checks distinguish systematic renaming from changed operations. Renaming a collaborator can preserve a copy; asking that collaborator to perform a different operation needs different evidence. Identical code requires source-text agreement under the whitespace rules, rather than merely equal normalized trees. The category guide explains how these labels relate to Type I, II, III and IV clones.

Make each comparison inspectable

Similarity measurements now belong to the two locations actually being compared. A large cluster no longer presents one selected pair's score as confidence for the whole group.

In VS Code, Compare To Canonical compares with the reference copy. Select for Compare and Compare with Selected let you choose another pair. The CLI's new --compare returns the engine's verdict for two explicit source ranges. Mass orders the work to review; it does not certify that extraction is safe.

Build artifacts are also excluded by recognized names and line shape, and generated-file banners are read from parsed comments. These checks keep the analysis focused on source code without treating a banner-like string literal as a generated-file declaration.

Measure accuracy beyond a pair count

The clone registers contain CLEARLY IN pairs that must be found and CLEARLY OUT pairs that must not be reported as clones. Uncertain examples are recorded without forcing a verdict. Comparisons use pinned repository revisions and account for older category names: an old shape-only result cannot satisfy a known-clone assertion.

We also inspect clone-range coverage: how much of the judged copied ranges the findings cover. A detector that finds only a small fragment of every copy can look good on pair correctness while still missing code users need to see.

A repository's duplication percentage answers a separate question: what fraction of analysed lines is covered by reported clones? It is not an accuracy score. Overlapping ranges count once, and shape-only findings count zero. Accuracy Transparency documents the calculation and the limits of corpus measurements.

The release work makes specific defects testable and comparisons easier to inspect. That is the evidence to ask of a static code analysis tool: which false matches were rejected, which missed copies were recovered, and whether the report shows the code a reviewer actually needs.