ALL-HIST0001 · large_file_the_team_keeps_reopening

Count long files this repository keeps changing anyway.

This is a deterministic rule for all languages. Read its implementation.

Definition

Report a file longer than minimum_lines with at least minimum_commits changes, whose change count reaches busy_share of the busiest file in the window, and whose last change is no older than stale_days. Size alone names a file that is hard to read, and plenty of long files are read once a year and cost nobody anything. Size beside repeated change names one the team is paying for over and over, which is a different and far more urgent thing, and only the history knows the second half.

Every threshold is relative or bounded on purpose. The busiest file sets the bar, so a quiet repository is not judged against a busy one, and a day count is read against the newest commit in the window rather than against the clock, so two runs over the same history agree.

Being relative is also why this is a measurement rather than a defect. The busiest file always reaches its own share, so any repository whose busiest file is long and current reports at least one however carefully it was written, and a ceiling of zero would only be restating the module size rules under a second name. What the count is worth is a judgment about ownership that the history cannot make, so the rule publishes the number and a project states the ceiling it wants held.

Continue with evidence and references, or open the examples.