kernighans-law — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited kernighans-law (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" — Brian Kernighan, 1974 (The Elements of Programming Style)
Writing clever code feels good. It demonstrates mastery and intelligence. But if you write code at the absolute limit of your ability to understand, you have no margin left to debug it when something goes wrong — and something will always go wrong.
The smarter move is to write code that is simpler than you're capable of. Leave yourself headroom.
Time to understand: Code that is dense, abstract, or uses advanced tricks is hard to read — for you, six months later, and especially for colleagues.
Debugging difficulty: When clever code breaks, the same cleverness that makes it compact also makes the failure mode opaque. You have to fully reconstruct the intent before you can find the bug.
Review friction: Code reviewers who don't immediately understand code are slower and less thorough. Bugs slip through.
Maintenance burden: Anyone who modifies the code must first understand it. Clever code has a high "understanding tax" that gets paid over and over.
Onboarding cost: New team members struggle with overly sophisticated patterns. Institutional knowledge doesn't transfer.
Explicit over implicit. If the reader has to mentally execute the code to understand what it does, it's too implicit. Prefer code that says what it means.
Verbose over terse when it aids clarity. A 10-line version that you can read in 30 seconds is faster to work with than a 2-line version that takes 5 minutes to parse.
Boring over brilliant. Use standard patterns that readers recognize instantly. Reserve unusual approaches for cases where they provide genuine, substantial benefits.
Comments that explain why, not what. When cleverness is unavoidable, comment the reasoning — not a restatement of the code. "We use XOR swap here to avoid an allocation in the hot path" is useful. "This swaps a and b using XOR" is not.
Kernighan's Law is not a blanket prohibition on sophisticated code. It's a warning to be honest about the costs. Cleverness is justified when:
When you're debugging code you wrote: if you can barely follow your own logic, that's the bug. The fix often isn't to trace the execution more carefully — it's to rewrite the code more simply, at which point the bug becomes obvious.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.