Skip to main content

ovecc selfcheck

Turns the tool on itself: for each rule, does the code it flags get corrected more often than the rest of the repository?

Usage: ovecc selfcheck

Rules are ranked by lift over the repository's own base rate, so a quiet codebase and a burning one are each judged against themselves. A lift of 2.0 means the files that rule flags attract twice the correction density of the average file.

Example​

$ ovecc selfcheck
Base rate: 0.06 fixes/KB over 129 file(s), 1913.0 KB (half-life 180 days)
  18% of the fix mass landed on paths the index does not hold — deleted files, docs, unsupported languages — and is in neither rate.

unresolved-import (lift 101.45)
  1 file(s), 0.3 KB, fix mass 2.00 -> 6.02 fixes/KB

architecture/behavioral-coupling (lift 1.93)
  4 file(s), 70.1 KB, fix mass 8.03 -> 0.11 fixes/KB

security/command-exec (lift 1.25)
  5 file(s), 198.3 KB, fix mass 14.68 -> 0.07 fixes/KB

unlisted-dependency (lift 1.02)
  5 file(s), 48.9 KB, fix mass 2.97 -> 0.06 fixes/KB

security/secret (lift 0.94)
  5 file(s), 322.1 KB, fix mass 18.06 -> 0.06 fixes/KB

A lift below 1.0 is not hidden. security/secret at 0.94 says that on this repository, that rule fires on code no more corrected than average — which is exactly what you would expect from a rule whose findings are all in test fixtures.

Why per kilobyte​

Rates are per kilobyte, not per file. Large files collect more findings and more corrections, so a per-file rate would flatter every rule that happens to fire on large files. Bytes rather than lines because bytes are what the index stores, and the lift is a ratio, so the unit cancels.

Fixes are age-weighted: a fix loses half its weight every 180 days, so a rule that was right two years ago does not coast on it.

Fix mass the index cannot see​

Fix mass that landed on paths the index does not hold — deleted files, docs, unsupported languages — is reported as a share and excluded from both rates.

Excluding it silently is how a self-check flatters itself: the files a team deletes are often the ones it fixed the most.

What the number does not show​

Association, not proof

Findings are computed on today's code while the corrections happened in the past. A rule can be right about code nobody has got round to fixing yet, and it will score poorly here.

There is no published bar to clear: the protocol is ours, and the figure ships whatever it says. Read it as one piece of evidence about which rules earn their noise on your repository, not as a verdict on the rule itself.

Empty without git history.

Options​

Only the global options.