A detekt rule fires constantly on your codebase — how do you decide between tuning, scoping, and disabling it?

## Why the question is asked A linter configuration is a written record of a team's craft standard, and the fastest way to destroy it is the reflex fix: the build went red, so the rule goes off. Interviewers ask this to find out whether you treat detekt's configuration as a design artefact or as an obstacle. The mature answer is a ladder of increasingly blunt levers, applied in order, with the blunt end used rarely and explicitly. ## Step 0: classify the findings Read twenty of them before touching anything. There are only three outcomes. The findings are **true** — the rule is doing its job and the code owes a change, possibly spread over several commits. The findings are **true but not worth acting on** in this code — for example magic numbers in a test fixture, where literal values are the point. Or the findings are **false for this idiom** — a rule written against a Java-shaped assumption firing on idiomatic Kotlin. Only the last two justify a configuration change, and they justify different ones. ## Lever 1: the rule's own options Most detekt rules ship with switches that encode legitimate exceptions, and reaching for them first is what separates a tuned config from a gutted one. `MagicNumber` alone carries `ignoreNumbers`, `ignorePropertyDeclaration`, `ignoreConstantDeclaration`, `ignoreCompanionObjectPropertyDeclaration`, `ignoreNamedArgument`, `ignoreEnums`, `ignoreRanges`, `ignoreHashCodeFunction` and `ignoreExtensionFunctions`. `LongParameterList` has `ignoreDataClasses` and `ignoreDefaultParameters`. `TooManyFunctions` has `ignorePrivate`, `ignoreInternal`, `ignoreOverridden` and `ignoreDeprecated`. Each of these keeps the rule enforcing its actual intent while removing a category of noise, which is exactly what you want: the signal survives. ## Lever 2: scope by path When the exception is a *place* rather than a *shape*, use the rule's `excludes` list of path globs — `excludes: ['**/test/**']` is the archetype. Test sources, generated code and Gradle script files are the usual candidates. This is narrower than disabling because production code stays covered, and it is far better than sprinkling annotations across hundreds of files. Note that a rule's `excludes`/`includes` are path patterns; the `excludes` list under the top-level `config` block is a different thing entirely — it exempts configuration *properties* from validation. ## Lever 3: move the number For the metric rules, changing the limit is legitimate when the codebase's idiom genuinely differs from the default — exhaustive `when` dispatch over a sealed hierarchy inflating cyclomatic complexity, or constructor injection inflating parameter counts. The test is whether you can state the number you can hold and then hold it. Raising a limit once with a recorded reason is a standard. Raising it every time the build goes red is an abandoned rule that still costs CI time. ## Lever 4: switch it off `active: false` is honest in one situation: the rule contradicts a convention the team chose deliberately. The clearest example is double-reporting — when another tool in the pipeline already owns a concern, leaving both enabled produces two findings for one problem and, worse, two sources of truth that can disagree. Turning one off is then a boundary decision, not an evasion. Say that in the config: an `active: false` with a comment explaining who owns the concern instead reads completely differently from a bare one. ## Keeping the configuration honest Three habits make this durable. **Comment every override** with the reason, in the `detekt.yml` itself. **Leave configuration validation on** (`config: validation: true`) so a misspelled property fails the run instead of silently doing nothing — a mistyped key is the quietest way to think you have a standard you do not have. And **review configuration changes like code**: a diff that turns a rule off deserves the same scrutiny as a diff that deletes a test, because that is structurally what it is. One-off exceptions do not belong here at all. A single justified violation is an `@Suppress` on that declaration with a comment; changing the project-wide configuration to accommodate one function inverts the cost.