Posted at
KotlinDay 10

kotlinとLintとEditorConfig

More than 1 year has passed since last update.

チーム内で個人のkotlinの技術成熟度は小鳥から大鳥1までプロジェクトで様々だと思います。自由度に合わせたコーディングルールが必要となるkotlinでの開発において、Lintがないのはやはり辛いですね。Lintを開発していただいてる世界中のエンジニアに感謝しつつ楽しみにしています。みなさんのプロジェクトではどんなルールがあり、それらをどう共通しているのでしょうか。


Android Lintとkotlin

残念ながら僕は参加してないのですが、先日のkotlinConfでLintに関するセッションがありました。

今後はコードをkotlinに置き換えつつ、より強力なサポートを追加してAndroid Lint2.0としていくそうです。しかし、現状ではAndroidLintはkotlinファイルの静的解析をIDEの機能からでしか行えません。

これはissueとしてあげられています。


Lint checks with Kotlin don't work from command line

Lint checks on Kotlin files only work from the Android Studio IDE. The currently do not run when you run lint directly from Gradle.


そのため、CIなどでいい感じに自動化できないです。これでは忘れてしまったり面倒でやらなかったりしてしまうのが世の常です。上記の発表でも告知されていますが、AndroidStudio3.1からサポートされ、gradleコマンドからLintをかければkotlinの静的解析が可能になります。


ktlint

AS3.1以降の安定したLintの提供はもう少し時間がかかりそうなので、何か別な手段でLintを行おうと調べていくと以下のような記事を見つけます。

コードレビューbotにKotlinコードのスタイルをチェックさせる

上の素晴らしい記事に触発されたので僕もプロジェクトにktlint入れるぞ

と、DangerやらAndroid Lintやらを準備していたら思わぬところに躓きました。ktlintではkotlinの公式Style Guideをベースにしていて、フォーマットに関する内容も含んでいてます。

例えばインデントに関して、kotlin Code Conversationsでは次のようにあります。


Naming Style

- use 4 space indentation


また、kotlin guideでも


Each time a new block or block-like construct is opened, the indent increases by four spaces. When the block ends, the indent returns to the previous indent level. The indent level applies to both code and comments throughout the block.


となっているため、インデントをスペース2つにしていると開発に嬉しくないワーニングが大量に出てしまうのでした…

。。。oO (it depends...

プロジェクトや個人の好みに応じて変化しやすい部分をLintに含めないでもらいたいというのが僕の主張ですが、


Kotlin linter in spirit of feross/standard (JavaScript) and gofmt (Go).


とのことなのでフォーマッターらしい部分も持っているようです。なので導入する前に相談してみました。

インデントに限らず、kotlinで記述するときはチームによって異なる部分はたくさんあると思います。他にも、


  • dataクラスにする基準は何か

  • importのフォーマットはどうするか

  • companion objectの位置はどうするか(ktlintでも議論されたようです

  • 改行はどこでするか

など、こういった細かなことを口伝していく開発は大変なので、可能なものはバシッとLintで解決していきたいのですが、そのktlintは簡単にカスタマイズできそうにありませんでした。

これでは

公式頼む
と待ち続けるしかない…

一瞬頭をよぎったのは面白そうなdetektを使ってみてCustomLintを作るか?!ということでしたが、自分たちのルールを決めるたびにを書いていくのはやや骨が折れそうです。(というか僕がいなくなったら誰もメンテしないなと)

ちなみにAndroidLintの場合、build.gradlelintOptionを指定できるので、そこで無視したいLintを記述できたりします。他にもwarningは表示しないなども可能です。


build.gradle

lintOptions {

disable 'YourDisableCase',~~
ignoreWarnings true
}


EditorConfig

万策尽きた〜と思っていたら、ktlintの0.11.02からEditorConfigのルールを読み込むようになったのをつい最近知りました笑

EditorConfigはIDEで一貫したコーディングスタイルを定義しておけるもので、現在のAndroidStudioではプラグインなどの導入なしに設定可能です。

なので、上のインデントでのワーニングは .editorconfig ファイルを追加するだけで回避できるようになりました。


.editorconfig

[*.{kt,kts}]

indent_size=2

他にもプロパティは色々あるのでチェックしてみてください。


以上で今回つまずいたポイントは簡単に解決できたわけですが、Lintで解決できないルールもあると思うので、おすすめの解決方法あればコメントなどいただけると嬉しいです。





  1. 学術上では大きさによる分類はないそうな 



  2. ちょうど議論していた頃にリリースされていたので、もうすこしちゃんとチェックしていればよかっただけですね…