Gate: sibling-guard
Sibling functions handle the same parameter consistently.
| Property | Value |
|---|---|
| Checker | sibling-guard |
| Confronts | code |
| Blocking by default — new project | yes |
| Blocking by default — existing project | no — informs |
How it measures
Section titled “How it measures”Confronts a module against its own internal asymmetry: when two sibling functions guard a parameter and a third does not, the one that does not is almost always forgetfulness, not decision.
The motivating case was real. A versioning module exported three functions over the same history. The TWO that wrote filtered the history by key before deciding; the one that READ did not filter — and it was exactly the one receiving the multi-key array straight from the repository. Asking for one key’s version returned another key’s, in silence. It passed 11 green gates and 16 tests.
The asymmetry is the signal, and it is what makes this detectable without understanding the domain. The gate does not know what the guard does, only that the siblings apply it and one does not. That is also why it cannot be a lint rule: nothing in the syntax is wrong.
Deliberately CONSERVATIVE. It accuses only when three conditions hold at once: three or more exported functions receive the same parameter name, the MAJORITY applies a recognisable guard over it, and at least one applies none. Below that bar it stays silent, because a false positive here teaches the team to ignore the gate — and a gate that is ignored defends nothing.
Declaring it
Section titled “Declaring it”gates: - name: sibling-guard on: [code] check: sibling-guard