Meet 'detekt', a static code analysis tool for Kotlin

1

Hello guys,

the last days I’ve spend my time writing a static code analysis tool for Kotlin.
Here it is → gitlabRepo and githubMirror

It currently supports 13 different rules categorized into three categories: code smells, style violations and document violations. (e.g. LongMethod/-Complex, LargeClass, LongParameterList, NamingConventions, MissingKDoc over public members, some style violations according to kotlin coding conventions etc).

It is organized in modules and uses the ServiceLoader-Pattern to be extendable by ownrules/rule sets. The module detekt-cli provides the currently only interface to analyze your projects.

In future I want to add more rules like GodClass and FeatureEnvy (+ more style violations) and write a gradle plugin to create reports on builds.

Feel free to file an issue with your ideas, thoughts and rule requests for the default rule set! Your feedback is very much appreciated. Thx in advance!

PS: I’m using Spek as the testing framework. On Bintray the version 1.1.18 was deleted when 1.1.19 was released. Is this the common way Bintray/Spek handles versions or is it done to the fact that the 1.1 is still in Beta? I don’t like my builds to fail on Jenkins, I’m using the experimental SubjectSpek class :frowning:

1 Like
2

The GitLab repo looks like it’s closed source…?

3

Thx! Now you should have access to the issues and code etc…

4

There’s a similar tool which you might want to consider joining forces with: GitHub - pinterest/ktlint: An anti-bikeshedding Kotlin linter with built-in formatter

1 Like
5

I had a good look on KtLint and found out it is specialized in findings formatting violations. I also use some similar mechanisms as KtLint but a more classical visitor approach with a KtTreeVisitor. As in KtLint were no new rules since august and one tool to have it all would be great, I made an effort to port the existing rules of it to detekt.

Today I released the third milestone with a total of seven rulesets (~45 rules). New rule sets are:

  • formatting - detects indentation and spacing problems in code
  • exceptions - too general exceptions are used in throw and catch statements like RuntimeException
  • empty - finds empty block statements
  • potential-bugs - code is structured in a way it can lead to bugs like ‘only equals but not hashcode is implemented’,
    no else case in when statements, explicit garbage collection calls

Formatting can be configurated to auto correct rule violations:

autoCorrect: true
formatting:
  ConsecutiveBlankLines:
    autoCorrect: false
  ...

If you are interested in testing detekt, you can add following to your gradle build file:

repositories {
    maven {
        url  "http://dl.bintray.com/arturbosch/code-analysis"
    }
}

configurations {
	detekt
}

task detekt(type: JavaExec) {
	main = "io.gitlab.arturbosch.detekt.cli.Main"
	classpath = configurations.detekt
	def input = "$project.projectDir.absolutePath"
	def config = "$project.projectDir/detekt.yml"
	def filters = ".*test.*"
	def rulesets = ""
	def params = [ '-p', input, '-c', config, '-f', filters, '-r', rulesets]
	args(params)
}

dependencies {
	detekt 'io.gitlab.arturbosch.detekt:detekt-cli:1.0.0.M3'
}

Credits go to Shyiko. Thx you for your attention. Pls open issues if you see something not working.

6

What are the main differences between detekt and ktlint (from a user’s perspective)?

7

ktlint checks your code if it is formatted according to kotlin style guide and detekt checks if your code is not too complicated (long methods, complex conditions, many parameters etc). detekt also provides a formatting rule set which is based on ktlint.

8

I gone through setup but it’s generating report with message “0 kotlin files were analyzed.” Any suggestion why !

9

Do we have any dcument stating, what should be the number of parameters (LongParameterList,)