ALL-HIST0001 · evidence

This page continues ALL-HIST0001 directly from its source docstring. Read its implementation.

Evidence

Each finding names the file, how long it is, how many commits touched it against the busiest file in the repository, and how many days ago that stopped. The repair is a choice, since a file everybody reopens is sometimes the one place a decision belongs. The value is the number of files scoring on all three.

Exceptions

A file seen in fewer than minimum_commits changes has not been reopened, and a file that stopped changing has already been paid for and is left alone, which is what stale_days buys. A generated file, a vendored dependency, and a lock file are long and busy without anybody reading them, so a project that keeps them in the tree excludes them rather than tuning the thresholds around them. A file the log holds but the tree no longer does reads as no lines at all and is never reported.

Nothing here fails on its own. A project that wants a churn budget states a numeric policy against this rule under tool.mcmr, and the count is then judged against that ceiling exactly as a rule-owned one would be, which is how a young repository and a decade-old one can hold themselves to different numbers without either editing the rule.

References

• Cites “Your Code as a Crime Scene”, chapter 4, hotspots as complexity beside churn
• Cites “Software Design X-Rays”, chapter 2, prioritizing technical debt
• Cites “Use of Relative Code Churn Measures to Predict System Defect Density”, ICSE 2005. Open reference