Eugen Martynov

    Eugen Martynov

    2 years ago
    can you share also value of detekt findings in your project?
    m

    Mike

    2 years ago
    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.
    Here's my copy. I have a number of imports not allowed to ensure people don't accidentally use JUnit4 (as we use 5 only), and that the Mockito matchers aren't used (we use Mockito with mockito-kotlin library)
    Eugen Martynov

    Eugen Martynov

    2 years ago
    thank you
    Can you also share value of Detekt for you? Obviously style rules are nothing error prone but just some agreements forcing
    Why it is valuable for you?
    m

    Mike

    2 years ago
    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.
    t

    taso

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

    Eugen Martynov

    2 years ago
    😃
    o

    oleg_osipenko

    2 years ago
    600 lines is nothing if you set you line to be 60 symbols wide 😄
    t

    taso

    2 years ago
    Why? Why? Do you hate programming? 😝
    a

    Artur Bosch

    2 years ago
    @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 🙂
    t

    taso

    2 years ago
    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 🙌