Rule

Is this rule specified as active in configuration? If a rule is not specified in the underlying configuration, we assume it should not be run.

List of rule ids which can optionally be used in suppress annotations to refer to this rule.

Does this rule have auto correct specified in configuration? For auto correction to work the rule set itself enable it.

The default names which can be used instead of this ruleId to refer to this rule in suppression's.

Rules are aware of the paths they should run on via configuration properties.

A rule is motivated to point out a specific issue in the code base.

Keeps track of which key was taken to subConfig this configuration. Sub-sequential calls to subConfig are tracked with '>' as a separator.

An id this rule is identified with. Conventionally the rule id is derived from the issue id as these two classes have a coexistence.

Wrapped configuration of the ruleSet this rule is in. Use valueOrDefault function to retrieve properties specified for the rule implementing this interface instead. Only use this property directly if you need a specific rule set property.

Clears previous findings. Normally this is done on every new KtFile analyzed and should be called by clients.

Reports a single new violation. By contract the implementation can check if this finding is already suppressed and should not get reported. An alias set can be given to additionally check if an alias was used when suppressing. Additionally suppression by rule set id is supported.

Same as report but reports a list of findings.

Simplified version of Context.report with rule defaults.

Tries to retrieve part of the configuration based on given key.

Retrieves a sub configuration or value based on given key. If configuration property cannot be found the specified default value is returned.

Retrieves a sub configuration or value based on given key. If the configuration property cannot be found, null is returned.

Init function to start visiting the KtFile. Can be overridden to start a different visiting process.

Basic mechanism to decide if a rule should run or not.

Before starting visiting kotlin elements, a check is performed if this rule should be triggered. Pre- and post-visit-hooks are executed before/after the visiting process. BindingContext holds the result of the semantic analysis of the source code by the Kotlin compiler. Rules that rely on symbols and types being resolved can use the BindingContext for this analysis. Note that detekt must receive the correct compile classpath for the code being analyzed otherwise the default value BindingContext.EMPTY will be used and it will not be possible for detekt to resolve types or symbols.