Ktlint

## What this question is really about ktlint is a linter and formatter for Kotlin. Like every linter, it needs an escape hatch: a place where a rule is right in general but wrong for one specific piece of code — a JUnit test method whose name is deliberately written in backticks or upper camel case, a generated-looking constant, a Kotlin file that mirrors a foreign API's naming. The interviewer is checking that you know the *current* escape hatch, because ktlint changed it in a breaking way at version 1.0 and a lot of blog posts and Stack Overflow answers still show the old one. ## The current mechanism: @Suppress with a qualified rule id ktlint honours Kotlin's standard `@Suppress` annotation. The string you pass is the ktlint rule id, prefixed with `ktlint:` and qualified with the id of the rule set it comes from: - `@Suppress("ktlint:standard:function-naming")` — a rule from ktlint's built-in `standard` rule set. - `@Suppress("ktlint:my-ruleset:my-rule")` — a rule from a custom rule set you or a third party wrote. - `@Suppress("ktlint")` — every ktlint rule, on that element. The qualification matters. Rule ids became fully qualified with their rule set id in the 0.49 line, so a bare `@Suppress("function-naming")` is not a ktlint suppression at all — the Kotlin compiler simply ignores an unknown suppression string, so the annotation compiles fine and the ktlint violation still fails your build. That silent no-op is exactly the trap this question probes. ## Scope: where you put the annotation `@Suppress` is an ordinary Kotlin annotation, so it obeys ordinary Kotlin scoping rules rather than anything ktlint-specific: - On a **declaration** — a class, object, function, property — it covers that declaration and everything nested inside it. Annotating a class suppresses the rule for all of its members. - As a **file-level annotation**, written as `@file:Suppress("ktlint:standard:filename")` above the `package` line, it covers the entire file. This is the form you need for rules that are inherently file-scoped, such as filename or import rules, because there is no single declaration to hang them on. There is no way to suppress a rule for a *range of lines* any more; that was precisely what the removed comment directives did. ## What replaced the comment directives Older ktlint supported `// ktlint-disable` at the end of a line, and a `// ktlint-disable <rule-id>` / `// ktlint-enable <rule-id>` pair to bracket a block. Those were deprecated in the 0.50 release and removed in ktlint 1.0. In a 1.x codebase they are inert comments: they neither suppress anything nor warn you loudly at the point of use. If you inherit a codebase full of them, expect a wave of "new" violations the moment you upgrade — the code did not change, the suppressions simply stopped applying. The reason for the change is worth being able to state: `@Suppress` is part of the language, so it is visible to the compiler, to IntelliJ, and to anyone reading the code, and it is scoped by the same rules as everything else in Kotlin. A comment directive is invisible to all of that and has to be re-implemented by every tool. ## Choosing the right instrument Inline suppression is one of three ways to make a ktlint violation go away, and interviewers like candidates who reach for the narrowest one: - **Fix the code.** The default. Most ktlint findings are trivially correctable. - **`@Suppress` on the declaration.** For a genuine local exception, where the surrounding code should still be checked. The annotation sits next to the code, so a reviewer sees the exception and can challenge it. - **Configuration.** When the rule is simply not this project's policy, turning it off centrally is honest and keeps the code free of annotation noise; a baseline serves the separate purpose of grandfathering pre-existing violations during adoption. A weak answer suppresses broadly — `@Suppress("ktlint")` on a whole class, or a file-level suppression to silence one function — because it hides violations nobody has looked at yet. A strong answer picks the narrowest scope and the exact rule id, and can explain why the annotation is preferable to sprinkling a rule off across the project.