Linter/analysis_options.yamlの話（とDart2.1対応コードへのマイグレーション関連を少し）

Dartでコードを書く場合、ほとんどの方が、JetBrains系のIDEやVisual Studio CodeにDartプラグイン（Flutterプラグイン）を導入されていることと思います。DartプラグインはDart Analysis Serverとの連携により、構文エラーやワーニングを示してくれます。今やIDEのサポート無しにはコードを書く気が起こらないほどです。

さてDart Analysis Serverは、パッケージがあるディレクトリ（pubspec.yamlがあるディレクトリ）に analysis_options.yaml ファイルが存在する場合、ファイルの内容に従いAnalyzerの挙動をカスタマイズすることができます。
https://www.dartlang.org/guides/language/analysis-options

今回は analysis_options.yaml ファイルの設定のうち、Linterに着目してみようと思います。

Linterの設定

前述のURLに示したページの通り、Linterの設定は下記の様な内容を analysis_options.yaml に記述することでカスタマイズ出来ます。

analysis_options.yaml

linter:
  rules:
    - avoid_empty_else # else文の実行が抜けていないか（else直後のセミコロン混入など）
    - cancel_subscriptions # StreamSubscriptionのcancelが抜けていないか（メモリリーク防止）
    - close_sinks # Sinkのcloseが抜けていないか（メモリリーク防止）
        ：

変数名の命名規則をどうするか、文字列リテラルをダブルクォートで囲むのを許すかシングルクォートに統一するか、インスタンス生成時にnewの使用を許すかnew無しに統一するのかなど、例え自分一人しかメンテしないコードであってもバラつきが無い方が良いです。公開するコードならなおさらです。一貫性、統一性が大事です。

Android StudioでFlutterのプロジェクトを新規生成した場合など、 analysis_options.yaml が生成されなかったりしますので、もし設定していない場合はお好みに合わせて設定することをお薦めします。
例えばAngularDartでは、以下の設定がされています。
https://github.com/dart-lang/angular/blob/master/analysis_options.yaml

Linterのもう一つの意義

一貫性、統一性とは別の意義が、Linterにはあると考えています。
それは、より読みやすい、又は明確なコードを書くことを助けてくれることです。

// BAD
class _Foo {
  _foo() => 42;
}

簡単な例ですが、上記は always_declare_return_types を設定することで、メソッドの戻り値の型が定義されていないことを指摘してくれます。

// GOOD
class _Foo {
  int _foo() => 42; // intを明記することでワーニングが消える
}

なおコーディングスタイルの指針として以下のドキュメントがありますが、Linterでカバーしていないものもあれば、Linterでそれ以上のチェックも可能だったりします。
https://www.dartlang.org/guides/language/effective-dart/style

Linterオプションのすべて

設定可能なオプションは、以下にすべて列挙されています。
http://dart-lang.github.io/linter/lints/options/options.html

オプションのそれぞれの意味は、ここから辿ることができます。
http://dart-lang.github.io/linter/lints/

なお、 analysis_options.yaml に設定したオプションであっても、コメントに ignore: とオプション名を記述すれば、ピンポイントでワーニングを抑止することが出来ます。

final name = element.displayName; // ignore:always_specify_types

ちなみに自分は以下の様に設定しています。
まず全部入りから初めて、徐々にチューニングしている最中です。
https://gist.github.com/takutaro/912b449cdd2814dd3dd8721d99bcca89

Dart2.1対応コードへのマイグレーション関連

mixin構文がDart2.1から追加されています。
prefer_mixin オプションを設定すれば、mixinに置き換え可能な箇所を見つけ出すことが容易になります。
http://dart-lang.github.io/linter/lints/prefer_mixin.html

また、double型の変数に与えるリテラルの扱いが変わりました。例えばFlutterで TextStyle(fontSize: 18.0) と書く必要があったDart2.0から、 TextStyle(fontSize: 18) の様に「.0」を書かずに済むようになりました。
オプションに prefer_int_literals を追加することで、整数リテラルで記述可能な箇所を見つけやすくなります（無理に過去のコードを修正する必要は無いかと思いますが、統一性を持たせたい場合は役立ちます）。
http://dart-lang.github.io/linter/lints/prefer_int_literals.html

この様に、新しい文法に追従したい場合にもLinterが役立つ場合があります。
（その意味では、デフォルトで全オプションが有効な状態から、必要に応じてオプションを抑止する方が個人的には嬉しかったかも）

まとめ

Linterを活用することで、コーディングスタイルについて、悩まない、読みやすい、明確である、一貫性を保てるという効果がありました。それだけでなく、例えば無闇に .forEach() を使っている場所があった等、気付ける/学べることもありました。
これからもLinterに助けられつつ、Dartコードを書いていきます。