Writing your first ktlint rule

As a matter of fact writing a rule for Detekt — another tool for analyzing Kotlin code — is very similar and this article is based on https://medium.com/@vanniktech/writing-your-first-detekt-rule-ee940e56428d

Almost never should you import types from an internal package like it is done below:

We don’t want to bother with things like this every time we review pull requests. Instead — a machine is much better at things like this. Hence we can write a ktlint rule that will detect internal imports.

It’s best to put your rules into a separate module (e.g. custom-ktlint-rules).

We’ll use the ktlint-api for writing our tests and for testing we can leverage the ktlint-test module.

This is all the code that’s needed for our custom rule. We’ll subclass from Rule and give it our name.

We’ll visit every ASTNode. If it’s of the KtImportDirective type we know we’re visiting an import statement. If the string importPath contains the internal word we can report it.

It’s effortless to test your rule as you can see below:

We pass our testing file as a string and can lint it. We verify that there’s exactly one Lint Error on the given file. It’s that easy.

We need to expose our rule. ktlint has a concept of a RuleSetProvider.

In the get method we return a RuleSet instance with our rule set id and our rule implementation.

To let ktlint know about this class we need to create a META-INF service file: custom-ktlint-rules/src/main/resources/META-INF/services/com.github.shyiko.ktlint.core.RuleSetProvider and contains the fully qualified name of our CustomRuleSetProvider: com.vanniktech.ktlintcustomrules.CustomRuleSetProvider.

This way ktlint can look up our class, instantiate it and use it via the RuleSetProvider interface.

Either you’re using one of the many Gradle plugins for ktlint or you’re wiring it up yourself. Internally — they all create a Gradle configuration. We know Gradle configurations already as api, implementation, testImplementation, etc. Typically — they create one called ktlint.

In your module where you want to use ktlint with your custom rule you’d add it like this:

This is all that needs to be done. When running from the command line it will look like this:

Writing your own rules is done in a breeze. There’s an initial work that needs to be done for setting up your environment but even that is quickly done.

For more complex things you can always look at the existing ktlint rules and see how they are able to retrieve information about your code.

If you have something that’s generally applicable create an issue on ktlint and let’s talk whether it should be baked as a ktlint rule — so everyone can benefit from it. I hope I’ll see some new faces contributing to ktlint.

You can find the entire example from this post in the GitHub repository below. Be sure to check it out.

Related posts:

This book is the introduction to Elixir for experienced programmers, completely updated for Elixir 1.6 and beyond. Explore functional programming without the academic overtones (tell me about monads just one more time). Create concurrent applications, butget them right without all the locking and consistency headaches. Meet Elix

Do you ever feel like life is just too hectic? Sometimes it feels like everything is getting to be too much. If this sounds familiar, there are many ways that you can instantly make yourself happier…

Wheelchair users now have wider options with improved mobility access in many areas across the country. Public transport and the workplace have been the areas where the most improvements have been…