can you share also value of detekt findings in your project?

We have it on failfast, which enables all rules with their defaults. We use the Gradle plugin, modifying Detekt to run after tests so it doesn't interfere with general development. We use the IntelliJ Detekt plugin so we see warnings while developing. All issues must be addressed in one way or another before pushing to CI server. Either fixing the code to address the issue, or deciding it's a 'false-positive', and Suppressing it. Some rules are turned off for tests. This way it's not possible to get a large backlog of issues that need to be addressed, and it's easy to see what types of things are being Suppressed by having it all in the code base.

thank you

Enforcing some basic rules around code. Especially useful to guide people new to Kotlin. Keeps coding style, and some other code choice decisions formalized, and enforced, rather than having to manually do them during code review.

Default rules are too broad. For example LargeClass rule was set to contain 600 lines of code. 600 lines of Kotlin code 😱

:)

600 lines is nothing if you set you line to be 60 symbols wide 😄

Why? Why? Do you hate programming? 😝

@Mike thanks for sharing! 600 lines for classes and 60 lines for functions is based on pmd (1000/100) minus the "experienced" 40% less code companies blog about when migrating from Java to Kotlin. Basically we are on the safe side and do not need to argue our thresholds. If you want more mathematical thresholds, you can run LargeClass and LongMethod with a threshold of 1, report every class/function and calculate some averages and standard deviantions and set your threshold to average + deviation or something 🙂

Makes sense. Thanks for the insights @Artur Bosch My joke was only about 60 char line width 😅 We already decreased it for our project. Setting it to 1 for calculation is a great idea 🙌