Formatting Code Analysis Rule with Android Lint (part 2/2)
For Kotlin and Java at once
TL;DR
In the first part of the article, we could see how easy it is to write a formatting lint rule for our coding conventions to automate a part of the code reviews. We also could see how useful Android Lint can be for formatting rules, despite that not being its basic purpose.
In this part, I’ll detail how to use my rule in any Android projects, and how to fix the already existing errors in our codebase. I’ll also show what testing library is provided by Android Lint and how I used it for testing and debugging my rule. Finally, I’ll write a few words about how Android Lint can be applied outside Android projects as well.
How to integrate a custom rule
In this tutorial, we can see the steps to do that using an extra module in our project. The difference here is that I pushed my compiled version of the rule to a Maven repository, so it can be integrated with just one line in any Android project, without any git submodules or similar solutions.
How to fix the already existing issues
Even though we always wanted to filter out this formatting issue by code review, sometimes we missed it, so we accumulated several issues in our codebases so far. It is quite boring to fix all the issues by hand, but fortunately, Android Lint gives support for auto fixing (see detailed in this article), which can be applied in two separate cases:
- By hitting the alt + enter keyboard combination
- By running the lintFix gradle task that automatically fix all the Android Lint issues that the quick fix feature is configured for:
The second option is more relevant for fixing the already existing issues, because it’s completely automatic. To configure the quick fix feature for my rule, I just need to pass a LintFix object when I invoke the report method. This quick fix appends one more line break to the single whitespace:
How to test a custom rule
Android Lint provides a testing framework as well, with which we can unit test our custom checks very comfortably.
- First, I need to write a snippet of code about a scenario, in which case I would expect an issue, if I want to check false negativity.
- Second, I have to point to the Issue object I expect in the issues method.
- Third, in the expect method, I can describe what errors I expect and where.
- Finally, I have a chance to test the quick fix mechanism as well by describing the expected diff after the fix in the expectFixDiffs method.
The steps are very similar for checking false positive cases; the only difference is that we use the expectClean method at the end.
Another great thing about unit testing is that syntax highlighting is supported if you use Android Studio, which minimizes the chance to write faulty code inside the test. This is a feature that is not available in other code analysis tools (such as Checkstyle, ktlint, or detekt).
Besides Kotlin, we can also write Java language specific tests. For that, we have to use the TestFiles.java(…) static method, and then the IDE can provide Java language syntax highlighting as well.
Debugging with unit tests
Using tests are currently the only way to debug a rule step by step, because otherwise the program runs in the IDE that you can’t launch in debug mode. By using tests, the debugging method is the same as debugging a unit test of any application; you can use breakpoints and evaluate the state of the program at any stage if you run it in debug mode.
Android Lint outside Android
Since Gradle 3.1.0, the tool is available for pure Java and Kotlin projects as well. See more information about the configuration in this tutorial. In a former Android Lint version (26.3) there was a bug as the article mentions, which made impossible to use custom rules with non-Android gradle modules. However, it was fixed in version 26.4, so we can leverage our Android Lint rules even on backend Kotlin/Java projects as well.
Conclusion
In this article, we could see that Android Lint is a mature tool; besides easy integration, it also provides a nice solution for auto-fixing your already existing issues. It also has a great testing library, which makes testing quite easy and comfortable. Finally, it’s great that they took steps to make Android Lint available for non-Android projects as well, which makes it even more competitive among the other code analysis tools.
References
If you are interested in Android Lint even more, I can really recommend this three talks:
- Getting the Most Out of Android Lint by Matthew Gharrity (Android Dev Summit ’18): https://www.youtube.com/watch?v=ffH-LD5uP4s
- Safe(r) Kotlin Code — Static Analysis Tools for Kotlin by Marvin Ramin (KotlinKonf ’18 ):
https://youtu.be/yjhQiP0329M - Kotlin Static Analysis with Android Lint by Tor Norbye (KotlinKonf ’17):
https://youtu.be/p8yX5-lPS6o
Source code
If you’re interested in my code more thoroughly, please use this Github link: https://github.com/team-supercharge/lint-checks.
