Back to browse
GitHub Repository

A linter for undocumented linter warnings.

3 starsRust

I built a linter for undocumented linter warnings. AI hates me now

by BKDDFS·May 19, 2026·2 points·1 comment

AI Analysis

●●SolidBig BrainNiche Gem

Forces devs to justify NOLINT comments before tech debt goes silent.

Strengths
  • Tracks suppression tokens across five languages including Rust and Python.
  • Integrates directly into CI pipelines to block undocumented suppressions.
  • Generates a shamefile.yaml report for code reviewers to audit decisions.
Weaknesses
  • Only catches suppressions matching specific token patterns in config.
  • Adoption requires team buy-in to enforce the workflow culturally.
Target Audience

Backend developers, tech leads, open source maintainers

Similar To

eslint · clippy · sonarqube

Post Description

You know the feeling? AI slaps a NOLINT instead of "thinking" for 5 seconds and "realising" it could do a 4-line refactor without adding a new suppression for the linter warning. Disgusted with this technology's narrowness, I usually say to it at that moment:

- WTF are you doin' bro? - "You are right! ^^ ..."

And at that moment I realise I've just irrevocably, regrettably lost 2 minutes of my life. Shame on you, Claude!

That's why I dedicated 2 months of my life to automate the thing (you know, I'm a programmer, hopeless case).

Humans were actually the original NOLINT-slappers, AI just does it at scale now. So I built a linter for linting other linter warnings to fight my colleagues' laziness and my own (mostly). Maybe you just caught a lag from the number of "lint" words but the idea is simple. Imagine a yaml file. Now add an entry to it:

- location: ./the-file.rs token: '// NOLINT' why: 'the reason'

Do you know what this NOLINT is? You don't? It's a suppression that you added 2 years ago. You don't remember? That's why you need shamefile. :)

Whoever's fault it is. Yours or the linter's. It doesn't matter. Document it, make sure you understand the code, get a review of your new entry in shamefile.yaml and let CI verify it. With shamefile your CI won't let any undocumented linter warning pass. Anymore. Instead of educating the business on why docs are important, you'll say: "quality tools won't let my code pass".

I've observed a noticeable difference in AI agents' behaviour. During the pre-commit phase, reasoning models can "rethink" adding a new shame entry. Not so easy now Claude, huh?

This is an early useable stage tool. We've been using it in prod for almost a month with my team and I'm using it in all my 3 OSS projects. Looking for feedback and contributors (adding new languages = good first issue ;))

Repo: https://github.com/BKDDFS/shamefile

Please tell me whether you'd use it or what I should change/add to make it usable for you. Also vote: shame me or shamefile sync, personality or matching the binary name?

Similar Projects