Motivation
After rude check succeeds, the only output is:
It is correct but unsatisfying — no signal that real work happened. On a fresh integration, a maintainer cannot tell at a glance whether rude:
- looked at the expected number of files,
- ran the expected number of rules,
- completed in a reasonable time.
Silence-on-success conflates "everything is fine" with "nothing was checked" (e.g. paths typo, select accidentally narrowed to zero rules via a broad ignore, glob mismatch). A one-line stat dispels that doubt cheaply.
Proposal
Append (files, rules, elapsed) to both the success and failure summary so the two paths are symmetric:
Success:
All checks passed (62 files, 87 rules, 0.42s)
Failure: (currently Found 3 error(s) and 2 warning(s))
Found 3 error(s) and 2 warning(s) (62 files, 87 rules, 0.42s)
With --fix:
Fixed 4 issue(s)
All checks passed (62 files, 87 rules, 0.42s)
Details
files: count of .py files actually analyzed (post-glob, post-skip).
rules: count of rule instances loaded after select/ignore/plugins/local-rules filtering — answers "what did rude really enforce?", not "what is built-in".
elapsed: wall time from after argument parsing to before summary print. Format Xms under 1 s, X.XXs above, to keep the visual scale obvious (850ms vs 12.50s rather than 0.85s vs 12.50s).
Optional, follow-on
- A
Skipped: N files (parse error) line when non-empty — silent skips are easy to miss.
- A
Auto-fixable: N issue(s) (rerun with --fix) line in the failure summary when any diagnostic has a [fix]. The per-diag [fix] marker is already there; a final count makes the call to action visible.
- Respect
--quiet: suppress the stats line in --quiet mode (machine-consumer territory).
Reference
Tried out while integrating rude into a downstream project — having the stats inline would have removed a "did this actually run?" verification step.
Motivation
After
rude checksucceeds, the only output is:It is correct but unsatisfying — no signal that real work happened. On a fresh integration, a maintainer cannot tell at a glance whether rude:
Silence-on-success conflates "everything is fine" with "nothing was checked" (e.g. paths typo,
selectaccidentally narrowed to zero rules via a broadignore, glob mismatch). A one-line stat dispels that doubt cheaply.Proposal
Append
(files, rules, elapsed)to both the success and failure summary so the two paths are symmetric:Success:
Failure: (currently
Found 3 error(s) and 2 warning(s))With
--fix:Details
files: count of.pyfiles actually analyzed (post-glob, post-skip).rules: count of rule instances loaded afterselect/ignore/plugins/local-rules filtering — answers "what did rude really enforce?", not "what is built-in".elapsed: wall time from after argument parsing to before summary print. FormatXmsunder 1 s,X.XXsabove, to keep the visual scale obvious (850msvs12.50srather than0.85svs12.50s).Optional, follow-on
Skipped: N files (parse error)line when non-empty — silent skips are easy to miss.Auto-fixable: N issue(s) (rerun with --fix)line in the failure summary when any diagnostic has a[fix]. The per-diag[fix]marker is already there; a final count makes the call to action visible.--quiet: suppress the stats line in--quietmode (machine-consumer territory).Reference
Tried out while integrating rude into a downstream project — having the stats inline would have removed a "did this actually run?" verification step.