fix(coding-dev): scoped suppressions, contribution-dependent precedence

- suppressions: prefer the narrowest scope that covers the problem (line,
  function, module) with a reason comment; a project-wide disable silences
  the rule in code nobody has written yet. Always name the specific rule.
  Propagated to rust (#[allow]), csharp (#pragma/SuppressMessage).
- precedence: a project's own rules win only when contributing upstream.
  For local/private work these rules win, adopting only the project's
  load-bearing conventions.
- type checking must pass with zero errors *or warnings*.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
BluscreamandClaude Opus 5 committed 2026-09-18 12:34:51 +02:00
1 parent 57968904bf
commit 9571eb52d2
4 files changed
+48 -17

No files matched your search

+11 -2
View File
@@ -61,8 +61,17 @@ workspace = true
> carries a second copy that drifts — which is how a binary once kept reading its own stale
> allows while the workspace's were being actively edited.
- **Never `#[allow]` on a whim.** If a lint is genuinely wrong for the codebase, allow it
**workspace-wide** with a comment explaining why, so the decision is visible.
- **Never `#[allow]` on a whim** — but when a lint is genuinely wrong for a piece of code,
**allow it at the narrowest scope that covers it** (the expression, the function, the
module) with a comment saying why:
```rust
// The FFI callback signature is fixed by the C API; we cannot take fewer arguments.
#[allow(clippy::too_many_arguments)]
extern "C" fn on_event(/* … */) { }
```
- A **workspace-wide** allow in `[workspace.lints]` is for the rare case where the lint is
wrong for the *entire* codebase — not a shortcut for one stubborn call site. It silences
the rule in code nobody has written yet.
- **Re-test every `#[allow]` periodically.** If removing one produces no warning, delete it.
- `too_many_lines` is the mechanical enforcement of the 100-line function limit. A function
that trips it wants extracting, not an allow.