detekt's ./gradlew detektGenerateConfig task copies the default configuration file to the location specified by the config property.

detekt {
  ...
  config = files(...)
  ...
}

When the file on this location already exists, your configuration won't be overwritten, and the task is a noop.

When we release a new version, some users like to generate the default one to compare changed properties. This can be done by running the detekt cli with the --generate-config --config [/new/location] flags. When already using Gradle, we can write a custom task and share this procedure with the team:

import io.gitlab.arturbosch.detekt.DetektGenerateConfigTask

val createDetektConfigForDiff by tasks.registering(DetektGenerateConfigTask::class) {
    description = "Generate newest default detekt config"
    config.setFrom(layout.buildDirectory.file("detekt-diff.yaml"))

    doFirst {
      // optionally delete the old config diff file first 
    }
}

The last step involves calling your favorite diff tool (e.g. diff detekt-diff.yaml my_config.yaml) or using an online service like http://incaseofstairs.com/jsdiff/.

Likewise we can diff the default config of detekt version X with the default config of detekt version X-1. This will tell us which properties are new in version X.

detekt's reporting mechanism relies on implementations of ConsoleReport's. The cli module and therefore the Gradle plugin implement a bunch of this reports.

A typical detekt report will look like following:

There are many different parts which might or might not interest you. If one part is not important to you, it can be excluded in the yaml configuration file. A silent configuration would exclude all possible processors and reports:

processors:
  active: true
  exclude:
    - 'DetektProgressListener'
    - 'FunctionCountProcessor'
    - 'PropertyCountProcessor'
    - 'ClassCountProcessor'
    - 'PackageCountProcessor'
    - 'KtFileCountProcessor'

console-reports:
  active: true
  exclude:
    - 'ProjectStatisticsReport'
    - 'ComplexityReport'
    - 'NotificationReport'
    - 'FindingsReport'
    - 'BuildFailureReport'

Running with this config won't produce any console messages:

Just verify that the ./report.txt is not empty ;).

We might find detekt's FindingsReport too verbose and just want to print one message line per finding. This can be achieved by implementing a custom ConsoleReport.

class SingleLineFindingsReport : ConsoleReport() {

    override fun render(detektion: Detektion): String? =
        detektion.findings.values
            .flatten()
            .joinToString("\n") { "${it.id} - ${it.message} - ${it.entity.location.file}" }
}

Combined with our silent configuration only messages are printed when findings are actually found:

See the extension documention on how to let detekt know about your custom report.

Today we are announcing the 1.0 release of detekt, a static code analysis tool for Kotlin. It operates on the abstract syntax tree provided by the Kotlin compiler and finds common programming flaws like unused or too complex constructs. Think of it as pmd or checkstyle but for Kotlin.

1.0 offers the following features:

• Code smell analysis for your Kotlin projects
• Complexity reports based on lines of code, cyclomatic complexity and amount of code smells
• Highly configurable rule sets
• Suppression of findings with Kotlin's @Suppress and Java's @SuppressWarnings annotations
• Specification of quality gates which will break your build
• Code Smell baseline for legacy projects
• Gradle plugin for code analysis via Gradle builds
• Gradle tasks to use local IntelliJ distribution for formatting and inspecting Kotlin code
• SonarQube integration
• Extensibility by enabling incorporation of personal rule sets, FileProcessListener's and OutputReport's
• IntelliJ integration
• Unofficial Maven plugin by Ozsie

Here are some metrics describing detekt's lifespan so far:

detekt is almost 3 years old already!
As GitHub tells us the project is pretty active.
You may argue that in 2018 it was more active looking at the number of commits, however that year we also changed our merge strategy from merge-with-rebase to squash-and-merge. That said, it is much harder to achieve these high commit numbers now ;).

There are 2516 commits, 52 releases on GitHub and a total 93 contributors at the time of writing. 20 out of the 93 authors contributed once or more in the last three months.

~780k downloads in the last 30 days is a pretty high number... three months ago it was around 500k. Weekends clearly stand out. That's when the CI has to rest ;).

This does however not mean one download equals one user. There are like eight detekt modules each with a jar and pom which needs to be downloaded. As most of the downloads are bound to be CI, it is hard to calculate the actual number of detekt users.

What I also noticed is the high number of "early adopters" in the Kotlin world (or just detekt).

• RC09 was released in Sep 2018
• RC10 was released in Nov 2018
• RC11 was released in Nov 2018
• RC12 was released in Dec 2018
• RC14 was released in Feb 2019
• RC15 was released in Jun 2019
• RC16 was released in Jun 2019

65% of users are on a version published in 2019. But we clearly lost some users in the older versions due to breaking changes in RC13 and RC15. We are excited to see how many users will jump on the 1.x.x release train and how these numbers will look like.

Last but not least here is a worldmap of where detekt users are coming from.

References:

• https://bintray.com/arturbosch/code-analysis/detekt#statistics
• https://github.com/detekt/detekt/graphs/contributors

detekt uses bintray for releases and artifactory for snapshots. To configure snapshot usage in your gradle plugin apply the following changes to your build file:

detekt {
    // if a new release of detekt stays binary compatible with a previous
    // release, just change the 'toolVersion'
    toolVersion = "1.0.0-RC16-20190629.171442-3"
    config = files("$projectDir/detekt/config.yml")
    baseline = file("$projectDir/baseline.xml")

    reports {
        html {
            enabled = true
            destination = file("$rootDir/detekt.html")
        }
    }
}

// this changes may be necessary if detekt's core modules like 'cli, core, api or rules'
// change in a way that is not binary compatible to older releases
dependencies {
    // use the detekt configuration for only official detekt modules
    detekt "io.gitlab.arturbosch.detekt:detekt-cli:1.0.0-RC16-20190629.171442-3"
    detekt "io.gitlab.arturbosch.detekt:detekt-core:1.0.0-RC16-20190629.171442-3"
    detekt "io.gitlab.arturbosch.detekt:detekt-api:1.0.0-RC16-20190629.171442-3"
    ...
    // use detektPlugins for detekt plugins - custom or official like the formatting one
    detektPlugins "io.gitlab.arturbosch.detekt:detekt-formatting:1.0.0-RC16-20190629.171442-3"
}

Starting with RC15 the test-pattern is obsolete. This post shows how to leverage rule path excludes to achieve the same functionality.

With version < RC15 the configuration file allowed to specify which paths should be mapped to test files so detekt would not run specific rule sets and rules on these test files:

test-pattern: # Configure exclusions for test sources
  active: true
  patterns: # Test file regexes
    - '.*/test/.*'
    - '.*Test.kt'
    - '.*Spec.kt'
  exclude-rule-sets:
    - 'comments'
  exclude-rules:
    - 'NamingRules'
    - 'WildcardImport'
    - 'MagicNumber'
    - 'MaxLineLength'
    - 'LateinitUsage'
    - 'StringLiteralDuplication'
    - 'SpreadOperator'
    - 'TooManyFunctions'

This was an okay approach as we nowadays separate production code and test code. However more different kinds of source files can be identified. For example generated and library code.

With the new approach of offering path patterns on the rule and rule set level the user has much more freedom in defining which rule should run on which path.

If we do not care about documented test classes because we write our test code in a documenting way, we could simply exclude the comments rule set for following patterns:

comments:
  ...
  excludes: "**/*Test.kt, **/*Spec.kt"

If we for example do not care about MagicNumber's in test code, we can exclude our test files for this rule:

style:
  ...
  MagicNumber:
    excludes: "**/*Test.kt, **/*Spec.kt"

Make sure to use globing patterns here as detekt does not support regular expressions anymore. This change was done to make use of the java.nio.file library when handling os-specific paths.

If you were using the default detekt configuration with the default test-pattern, you will not notice any changes when upgrading to >= RC15. All exclude-rules and exclude-rule-sets will now make use of excludes: "**/test/**,**/*Test.kt,**/*Spec.kt".

A common use case of detekt users was to build upon the default config file and use a second config file to override some defaults. Speaking in Gradle terms, this could look like following:

detekt {
    ...
    config = files(
            project.rootDir.resolve("config/default-detekt-config.yml"),
            project.rootDir.resolve("config/our.yml")
    )
    baseline = project.rootDir.resolve("config/baseline.xml")
    ...
}

Starting from RC13, two new commandline flags got introduced:

• --fail-fast
• and --build-upon-default-config
• (buildUponDefaultConfig and failFast properties for gradle setup)

Both options allow us to use the distributed default-detekt-config.yml as the backup configuration when no rule configuration is found in the specified configuration (--config or config = ...).
This allows us to simplify our detekt setup without copy-pasting a huge config file:

detekt {
    ...
    buildUponDefaultConfig = true
    config = files(project.rootDir.resolve("config/our.yml"))
    baseline = project.rootDir.resolve("config/baseline.xml")
    ...
}

{% include links.html %}

When configuring detekt for your Gradle based project, you basically have two options:

• for each sub module a new gradle task should be created
• or one uber-task analyzes your whole project

For the first option, please see how detekt itself creates a task for each module:

subprojecs {
...
    detekt {
        debug = true
        toolVersion = usedDetektVersion
        buildUponDefaultConfig = true
        config = files(project.rootDir.resolve("reports/failfast.yml"))
        baseline = project.rootDir.resolve("reports/baseline.xml")
    
        reports {
            xml.enabled = true
            html.enabled = true
        }
    }
}

Sometimes it makes sense to add an additional detekt task which runs over the whole project and produces one big report. Such a setup could look like the following in its simplest form:

plugins {
    id "io.gitlab.arturbosch.detekt" version "1.0.0-RC14"
}

repositories {
    jcenter()
}

detekt {
    source = files(rootProject.rootDir)
    buildUponDefaultConfig = true
}

Make sure to specify the input parameter or no sources are found and detekt won't run!

If you need more fine grained detekt tasks, you could register more tasks using the Detekt task as the base task. Using the Kotlin-Dsl it could look like this:

val detektAll by tasks.registering(Detekt::class) {
    description = "Runs over whole code base without the starting overhead for each module."
    parallel = true
    buildUponDefaultConfig = true
    setSource(files(projectDir))
    config = files(project.rootDir.resolve("reports/failfast.yml"))
    include("**/*.kt")
    include("**/*.kts")
    exclude("resources/")
    exclude("build/")
    baseline.set(project.rootDir.resolve("reports/baseline.xml"))
    reports {
        xml.enabled = false
        html.enabled = false
    }
}

{% include links.html %}

As of today the website was launched!

{% include links.html %}