It seems a more logical choice, because we use both languages in our Android projects, and I wanted neither to write the same rule twice nor maintain them concurrently. We can say that ktlint for Kotlin and Checkstyle for Java are the main formatting code analysis tools, but now I’ll pick another tool yet: Android Lint (not only for Android projects), because it also supports writing custom rules that can be applied to Kotlin and Java at the same time. We believe this makes our code more readable, that’s why we always leave a comment during code review if someone violates this rule (and if we happen to notice it). We always require double line breaks before and after “block statements”, which can be if, switch ( when in Kotlin), for, try, or while blocks, unless they are exactly at the beginning or the end of a method or another block. Missing empty line around “block statements” issue I decided to write one for the most common formatting mistakes we make: For those cases, the above-mentioned tools support adding custom rules as well. We use several lint tools, such as ktlint or Checkstyle, for enforcing global formatting conventions (variable order, line length, etc.), but these don’t include certain company-wide rules by default. That’s why I started thinking about ways we could automate fixing this minor (yet important) problem, so we could focus on more complex issues during code reviews. Sometimes, we have to change branches in order to fix a single formatting error in our MR, which is quite demotivating. I get frustrated when I get formatting-related comments on my merge requests or when I have to add such comments to others’. For inspiration, I’ll also show the steps I took to make my formatting rule work with Android Lint. I’ll explain its main advantage in my case against the other tools, and describe the inner workings that provide this benefit. Secondly, I want to demonstrate that in addition to Checkstyle and ktlint, Android Lint should also be considered when creating a formatting-related code analysis rule, despite that not being its basic purpose. In this first part of the article, primarily, I want to show that it’s worth the time to write a custom code analysis rule to enforce code conventions.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |