February 2, 2026
Ratchet or Racket?
Ratchets in Software Development
A tiny ‘code cop’ counts bad habits while devs argue if it’s genius or joykill
TLDR: A simple script caps “forbidden” code so bad habits stop spreading. Commenters split between praising practical guardrails, calling it just a fussy lint rule, and joking about sneaky workarounds—spotlighting the tug-of-war between tool‑enforced discipline and actually cleaning up old code.
An engineer unveiled a “ratchet” — a tiny script that counts how many times a team uses a forbidden method and refuses to let that number go up. It’s basically a tally check during linting (the code’s spell-check), with hilariously blunt rules: if the count goes down, celebrate and lower the expected number; if it goes up, block it. Edge cases like mentions in comments? Shrug. Plans include adding regular expressions (fancier pattern matching) and auto-downratcheting, but the author warns about sinking time into a tool rabbit hole.
Cue the community drama: some shouted “finally!”, like dgoldstein0 who built a version with ripgrep, a linter, and Continuous Integration (robots that check code before it ships), while burticlies went full rant: why don’t linters do this already? People hate drowning in yellow lines that everyone ignores. Others pushed back: arnorhs says it’s just a lint rule with an annoying hard-coded count. Meanwhile, thraxil linked their own take on ratchets here and dependency_2x dubbed it grandfathering — like code coverage rules that get stricter over time — then joked about sneaky devs deleting old “bad” calls just to add new ones. The vibe: code cop vs copy‑paste culture, plus popcorn gifs while the count ratchets down.
Key Points
- •A lint-time “ratchet” script counts occurrences of discouraged patterns and raises errors when counts increase or decrease.
- •Expected counts are hard-coded; decreases prompt developers to lower the configured threshold.
- •The script targets method names from first- and third-party libraries acceptable generally but discouraged locally.
- •Detection uses basic string matching without source parsing; edge cases like comments and literals have not been problematic.
- •Planned enhancements include regex support, clearer errors, automatic ratcheting down, and a more flexible configuration interface.