Handling detekt lint issues on Android

Detekt is a configurable lint tool for Kotlin that can be used to find code smells within your Android project. In the previous blog post, we discussed how to integrate detekt in your project. Now we will explore what to do when we discover lint issues.

Tip - detekt generates a report after the lint scan that includes the issue with code snippets as well as a suggestion to resolve it.

When running detekt for the first time, you may encounter hundreds of lint issues like in the report shown above. This is fine! Normally, a software project accumulates technical debt over time. Instead of jumping to solve all of the issues in one go, let's break down different strategies you can use to deal with this situation.

When encountering any type of lint issue, you can

1. Fix the issues that are critical or can be resolved easily
2. Disable or modify the rule to meet your specifications
3. Suppress the issue until it can be fixed at a later date

Dealing with lint issues

Fix the issue

It may not be a good idea to try to solve all of the issues in the lint report. Instead, analyze which issues are critical or can be resolved easily. The goal of using a linter is to keep the project in a good state which includes resolving all of the current issues and preventing any issues being merged into the codebase.

For issues that are critical or can be resolved easily, simply implement the solution to satisfy the rule and re-run detekt to verify that the issue has been fixed.

Disable or modify the rule

Not all issues will be important to your project. If you feel there is a rule that does not make sense to enforce, you can disable it through the configuration. This will prevent the lint scan from alerting you of this issue in the future, so use it with caution. You also have the ability to modify the threshold of a specific rule. Some rules can be customized to take on a lower or higher threshold value, so they will only alert if that particular threshold has been crossed.

Detekt uses the default ruleset upon integration. To disable or modify a rule, simply add the default configuration file into the project and make a reference of it in build.gradle file. Then make any changes to the configuration yml file and push it to the code repository.

/** build.gradle (app) */

detekt {
    // Define the detekt configuration(s) you want to use.
    // Defaults to the default detekt configuration.
    config = files("path/to/config.yml")
    ...
}

Reference: https://detekt.github.io/detekt/configurations.html

Suppress the issue

In the case where fixing or modifying the rule might not possible, you can suppress the issue until it can be fixed at a later date. This is the preferred alternative to disabling a rule, since it allows you keep scanning for that particular in future scans as well as keep track of the technical debt that has been accepted as of now. You can suppress an issue by adding the suppress annotation with the rule name in the class that contain the issue. All subsequent lint scans will not alert on that particular issue.

Another way to suppress issues is by adding it to the baseline. A baseline file is a file that tracks all of the current lint issues and ignores it for subsequent lint scans. This accepts the current technical debt and only alerts when new issues are being added to the codebase. Detekt can generate a baseline file for you by running the ./gradlew detektBaseline task in terminal. Once completed, make a reference of the file in the build.gradle file and push it to the code repository.

/** build.gradle (app) */

detekt {
    // Specifying a baseline file. All findings stored in this file in subsequent runs of detekt.
    baseline = file("path/to/baseline.xml")
    ...
}

Conclusion

Setting up a lint tool can be a scary and overwhelming task, especially dealing with hundreds of lint issues. Once everything is set up, we can ensure that software quality will be maintained on the codebase. During the time of this blog post, I was able to fix 112 out of the 117 issues which were quite easy to fix. As for the remaining 5 issues, I added them to my baseline. With detekt in place, I can continue writing more code knowing that I am following the best practices and not introducing any code smells in the codebase.

That's a wrap! Stay tuned for more blog posts.