What separates a justified inline suppression of an analyser finding from one that only silences the gate?
answer
- The gate is loudest exactly when it matters
- Narrow, named, explained, revisitable
- The reason is the reviewable artefact
- Count them next to the gate number
- Dozens of one rule is a configuration decision
basics
~20 sA justified suppression names the specific rule, covers the narrowest possible scope, and carries a written reason a reviewer can check against the code. A scope-wide suppression with no rule named and no reason is indistinguishable from hiding a real defect.
solid answer
~40 sApply four tests. It names the rule, so nothing else is silenced by accident. It covers the smallest scope that works - one statement or one declaration rather than a file or a module. It carries a reason that states what the analyser cannot see, not the word `false positive`. And it has an owner or a tracking reference, so it can be revisited rather than living forever. Beyond the individual site, suppressions need auditing in aggregate: they are invisible to a baseline ratchet, so a team can report zero new findings while suppressing every one of them, and the two numbers have to be read together. If one rule is being suppressed at dozens of sites, the decision belongs at the rule's configuration rather than at each site.
code
pseudocode · 8 lines# unreviewable: no rule named, whole file, no checkable reason
@suppress_all # false positive
file ledger_ingest
# reviewable: one rule, one declaration, a claim a reviewer can test
@suppress("unchecked-cast", reason = "record shape is fixed by the ingest schema check in validate_batch(); tracked as LEDGER-8142, revisit when the ingest schema check moves")
function read_stock_record(row):
return row as StockRecordgo deeper
Know that suppressing a finding is allowed but must be explained, and that the annotation should name the one rule and sit on the smallest piece of code that works rather than on the whole file.
Be able to justify a suppression in review: what the analyser cannot see, why the narrow scope is enough, and how someone would know later whether the exemption is still needed.
Show the aggregate view. Suppressions are invisible to a ratcheting gate, so a clean gate plus a rising suppression count means findings are being hidden, and repeated suppression of one rule is a configuration decision rather than a coding one.
Own the norms across teams: what a reason must contain, which scopes are permitted at all, how suppressions are counted and reported alongside the gate, and how false positives get routed back to whoever maintains the rules instead of being re-suppressed forever.
## Suppression versus baseline Both mechanisms excuse a finding, but they differ in every property that matters. A baseline is external, bulk and generated: one command records thousands of findings, and no human argued for any of them individually. An inline suppression lives in the source at the exact site, is written by hand, is read by every future maintainer of that code, and is reviewed in the change that introduces it. That makes suppression the more accountable mechanism and also the more dangerous one, because it is available at the moment of writing new code - which is precisely when the gate is supposed to be saying no. ## The four tests **Named rule.** A suppression that names the specific rule silences that rule only. A bare suppression with no rule named silences everything the analyser might ever say about that code, including rules added next year. The second form is nearly always wrong, and spotting it in review is the cheapest quality intervention available. **Narrowest scope.** Scope runs from a single statement or declaration up through a class or a whole file to a directory-wide configuration exclusion. Each widening step brings in code the author never considered. The classic abuse is the file-level suppression added to fix one line, which then quietly covers 800 more lines as the file grows over the following year. **A reason a reviewer can check.** `false positive` is not a reason; it is a claim. A reason says what the analyser cannot see: that the caller has already validated the identifier, that the value is guaranteed non-empty by a database constraint, that the reflective call is exercised by a specific test. A reviewer can agree or disagree with that sentence. Nobody can review the word `false positive`. **An owner or an expiry.** A suppression that references a tracked item, a date, or at minimum an author, can be revisited. One with none becomes permanent by default, because no future reader has the standing to remove something whose purpose they cannot reconstruct. ## Reading suppressions in aggregate The single most useful operational habit is counting them. Suppressions are invisible to a ratcheting gate: a suppressed finding is never reported, so it never appears as new work and never enters the baseline. A team can therefore hold a perfect record of zero new findings while suppressing each one as it arises, and the pipeline will show green throughout. Reading the suppression count next to the ratchet is what closes that hole. On the stock-ledger service, eight weeks of a clean gate came with 46 new suppressions - and one of them was on an unchecked read of a stored ledger record, annotated only `analyser is wrong`. It was wrong at the time it was written and became wrong in fact when the record shape drifted a release train later, so the read failed as a schema-drift mismatch in production. The finding had been correct; the reason had never been checkable. ## When the site is the wrong place to fix it If a single rule accumulates suppressions at dozens of sites, the per-site mechanism is being asked to carry a decision that belongs one level up. Either the rule does not fit this codebase - in which case its configuration, scope or severity is the thing to change, deliberately and once - or the codebase genuinely violates it everywhere, in which case the honest move is a baseline entry set plus a paydown plan, not scattered annotations that hide the size of the problem. Either way, dozens of suppressions of one rule is a signal to stop and decide, not a pattern to continue. ## Review posture Treat a suppression introduced in the same change as new code as a specific thing to discuss, not a detail. The useful reviewer questions are short: which rule does this silence, what would happen if it were removed, and what does the reason claim that the analyser cannot see? A suppression that survives those three questions is usually genuine. If the finding really is a false positive in the tool rather than in the code, the suppression should say so with the evidence, and the case should be reported to whoever maintains the analyser - otherwise the same false positive is suppressed independently in twenty places forever. ## The summary an interviewer wants Suppression is legitimate and necessary; every analyser is wrong sometimes, and code sometimes has a good reason to break a rule. What separates the discipline from the abuse is that a justified suppression is *narrow, named, explained and revisitable*, and that the total number of them is watched as carefully as the number of findings - because a gate that only counts what it is allowed to see can be satisfied without any of the code getting better.
- Why is a file-wide suppression worse than the same suppression on one declaration?Because its scope grows without anyone deciding that it should. It was added for one line, but it covers every line added to that file afterwards, including code written years later by people who never saw the original reason. The narrow form fails loudly when a second site needs the same exemption, which is exactly the conversation you want.
- A team reports no new analyser findings for two months. What would you check before believing it?The suppression count and the baseline size over the same window. Suppressed findings are never reported, so they never register as new work, and a baseline that was regenerated has the same effect. A clean gate is only evidence when the suppression total is flat and the baseline moved downwards over the period.
- The analyser really is producing a false positive. What is the right response beyond suppressing it?Suppress narrowly with a reason that states why the tool is wrong, then report the case upstream to whoever maintains the analyser or the ruleset, with a minimal reproduction. Otherwise the same false positive is rediscovered and suppressed independently across the codebase, and nobody ever accumulates the evidence that would get it fixed.
saying these in an interview costs you the question
- Writes `false positive` as the entire justification
- Suppresses at file or module scope to silence one line
- Uses a blanket suppression that names no rule
- Treats a clean gate as proof while suppressions climb
- Never revisits a suppression once it is merged
- Scatters the same suppression instead of deciding at rule level