追記 (2021/9/10)

無事、Flutter 2.5.0 が Stable になり、flutter_lints が Stable にやってきました　 🙌

本編

こんにちはこんばんわ、すぎっと ٩( ᐛ )و です
今日のテーマは Linter です。リンターと読みます。

実は先日、Flutter の Issue サーフィン (謎趣味）をしていたところ、こんなものを見つけました。

そしてこの PR です。

ということはそろそろアナウンスがくるかな〜と思っていたら、

来ました ٩( ᐛ )و

内容については後ほど触れようと思いますが、まずは先に結論だけ示しておきます。

これによって何が起きたかと言うと、

"flutter create my_app"で作ることができる Flutter のテンプレートアプリに Linter が導入されるようになりました

Flutter 公式がテンプレートを変更してきました。これは事件ですね！
早速、どんなことが変わったのか見ていこうと思います。

Linter って何?

ソースコード警察 👮🏻‍♂️ 　です。

Flutter や Dart 以外のフレームワークや言語に慣れ親しんだ方なら、それら各方面での Linter を使っていると言う方は少なくないと思います。ここでは Linter ってはじめての方に向けて少しだけ簡単な説明をしておこうと思います。

まず、 Linter の役割は 静的解析 と言われるものです。ここでいう静的とは、アプリを実行する前 の段階でソースコードを解析し、必要な情報を教えてくれるものを指します。自動テストも静的解析と呼ばれたりしますので、静的解析というのは結構広義なものなのかなぁと思います。定義としては、「実行可能なプログラムを実行せずとも、プログラムの問題（または問題になりそうな箇所）を解析して見つけ出そう」というものだと思います。正確な定義はググってください。

つまり、Linter とは 静的解析ツール の 1 つであり、Flutter アプリをビルドすることなく、そのソースコードを解析し一定のルールに従わない箇所を提示してくれるプログラムを指します。そういう意味で、アプリ開発における「警察」って言われたりしますね。（私だけ・・・？）

さて、サラッと書きましたが「一定のルールに従わない箇所」がミソです。

通常、Linter はルールにしたがってソースコードを解析するプログラムそれ自体を指します。したがって、Linter を使う側であるアプリ開発者は、Linter という静的解析プログラムに対して 「ルール」を提供してあげる ことがその役割と言うことになります。では、Flutter ではどうやってルールを提供するのでしょうか。そもそもルールって何なのでしょうか。

この記事ではその辺りの説明を交えつつ、今回新しく Flutter のテンプレートに追加されたルールについて触れていこうと思います。

どうして Linter が必要なの?

プログラミング言語毎の性質にもよりますが、どの言語であってもソースコードというのはその目的に対して比較的自由なものです。そのため、どんな言語であっても、ベストプラクティスな書き方、公式推奨/非推奨の書き方、というものがあります。プログラマーは日々勉強を重ねながら、より良い書き方というのを更新し続けているような生き物だと思います。

では、組織に属したプログラマー集団が 1 つのアプリを作るとします。

それなりに成熟した組織であれば、コーディング規約 というローカルルールのようなものをドキュメントとして持っていると思います。通常、その組織に新たに参画し、プロジェクトにアサインされたときはその規約に目を通し、規約に従った実装が求められます。集団に属するというのはそういうものです。
昔はそれで良かったのですが、最近はコーディング規約という文書を読んで人がそれに従うというのは、実装者・レビュアー双方にとって負荷が高い と言われます。当然のように見落としは頻発しますし、それによってソースコードはどんどん汚れていき、終いにはその見落としが パフォーマンスを著しく低下させる といったことがあります。

プログラマーはいかに手を抜くかということに全力を尽くす生き物です。Linter はまさにそれです。コーディング規約というルールをプログラムが解釈可能な形で定義してあげることで、その ソースコードを常に監視できる 状態にしました。これによって、実装者もレビュアーも規約にしたがっているかどうかというチェックに気を使わなくて良くなりました。

このルールに従うという行為ですが、単にソースコードの見た目が揃うということに加えて、一定の品質を担保できる というメリットがあります。これがとても大きなメリットになります。

たとえば Flutter で言えば、

「書き変わる見込みのない Widget には const をつけておこうね」

と言うものがあります（以下）。

これは、Widget に対応する RenderObject の生成コストがバカにならないので、Widget の定義が変わらないなら保持して再利用した方がパフォーマンス的に良いよね、と言うものです。Flutter のパフォーマンス改善としてまずやっておこうぜ、と言われるものですね。

こういったものをルールとして、Linter というプログラムを実行することで、実装者が const をつけ忘れたとしても Linter が "const つけや〜" と教えてくれるようになります。

こんな感じですね

Flutter の Linter って前からあったの?

もちろんありました。

pedantic
effective_dart

が有名だったのですが、いずれも deprecated になりました。

https://pub.dev/packages/pedantic

https://pub.dev/packages/effective_dart

deprecated になったのはなぜか？

まず pedantic の readme にこんなことが記載されていました。

This package is deprecated.

Before it was deprecated, it was the way to get analysis options matching those used internally at Google. This was useful because it was a good starting point for which lints to enable.
Instead, please see package:lints which is the lint recommendation from the Dart team, or package:flutter_lints which extends that for Flutter. These are better than the Google lint set because they take into account the needs of all Dart users, not just Google engineers.

また、effective_dart にもこんな記載がありました。

This package is deprecated.

Before it was deprecated, it was the way to provide analysis options corresponding to the guidelines in Effective Dart.
Instead, please see official packages: package:lints which is the lint recommendation from the Dart team, or package:flutter_lints which extends that for Flutter.

いずれのパッケージも、Flutter がオフィシャルに 推奨ルール を示したので、そっちを使ってね、と言っています。

私も pedantic には大変お世話になったのですが、感謝の気持ちをもって、新しいパッケージへお引っ越ししました。

Linter ってどうやって設定するの?

analysis_options.yaml を書けば良いのです。
この記事の最初にリンクを貼りましたが、再掲します。

すべてがここで説明されていますので、概要だけ説明します。

flutter_lints: ^1.0.0 を入れます！（パッケージのバージョンは随時チェックしてください）
analysis_options.yaml を Flutter プロジェクトのトップにおきます。（pubspec.yaml と同じ階層です）

以上です。

参考に、Flutter 2.3.0 - 12.0pre で導入された analysis_options.yaml はこんなファイルです。

flutter_lints にはどんなルールがあるの?

flutter_lints には Flutter が公式に推奨しているルールセットが定義されています。先に提示したテンプレートの analysis_options.yaml は、パッケージとして追加された flutter_lints から推奨ルールセットを取り込んでいます。include: package:flutter_lints/flutter.yaml この部分ですね。

もしルールを追加したい場合は、analysis_options.yaml にルールを追記すれば、

flutter_lints の推奨ルール + 独自の指定ルール

で運用できます。

ということはですね、flutter_lints が提案している 推奨ルールセット に何が含まれているのかを把握しておいた方が良いですね。

・・・

とは言いましたが、ものすごい数があります。

正直言って、どんなルールがあるかをチェックするより、怒られたら直す というスタンスでいいと思います。

一応見ておきましょう。

flutter_lints

ここにある通りです。
おやおや、 include: package:lints/recommended.yaml とありますね。といことは、lints/recommended.yamlからルールを取り込んでいますね。

lints/recommended

めっちゃ多い・・・( ᐛ )

しかも include: package:lints/core.yaml してありますねぇ。

lints/core

やっと終わりました。

ルールの定義

各ルールの意味が知りたい場合は以下のページから参照できます。また、独自にルールを追加したい場合も以下の Dart lints から選択します。

Linter に怒られたけど、どうやって直したらいいのかわからないよ〜！

というときは、以下のページからエラーメッセージのキーワードを検索してあげれば Good & Bad なコードが書かれていますので、理解の手助けになると思います。

たとえばさきほどの const の件であれば、

prefer_const_constructors がルールの名前ですね。これで検索してあげてください。

追記: 誤解を防ぐために

mono さんの pedantic_mono が flutter_lints をベースとするものにパワーアップされました。仕事が早い…

https://pub.dev/packages/pedantic_mono

その中で、こんなことをおっしゃられていました。

あ〜自分の記事がこの誤解を招いてたらいやだなぁと思ったので追記します。
ちゃんと読めば flutter_lints がデフォルトになっただけで、analysis_options.yaml に独自に選んだルールを足せばよいというのは伝わると思うのですが、走り読みをすると

そうか〜🤤
pedantic と effective_dart が deprecated になったのか〜🤤
これからは flutter_lints なのか〜🤤

みたいな、パッケージ選定の話みたいに捉えられかねないなぁと思ったからです。

大事なのはあくまで "ルールセット" です。

パッケージに何を使うかというのは、自分が採用したい ルールセット を基準に選んでください。
その際のベースラインのようなものとして、flutter_lints が出てきた、と思ってください。

これまで Linter を導入してこなかった方へ
- まずは flutter_lints からはじめてみてはいかがでしょうか？　 Linter 無しは卒業しましょう。
これまで Linter を使っていた方へ
- flutter_lints が持つルールと、いま使っているルールを比べてみてください。そして、必要に応じて追加してください。
もっと Linter を使いこなしたい方へ
- Linter のルール集を作っているパッケージはいくつかあります。それらを参考に自分のプロジェクトに導入可能なルールがあれば積極的に採用しましょう。また、使用しているパッケージが推奨するルールがある場合もあります。そういったものも参考にしてみてください。

参考

flutter_lints だけで有効になるルール集

always_require_non_null_named_parameters
annotate_overrides
avoid_empty_else
avoid_function_literals_in_foreach_calls
avoid_init_to_null
avoid_null_checks_in_equality_operators
avoid_print
avoid_relative_lib_imports
avoid_renaming_method_parameters
avoid_return_types_on_setters
avoid_returning_null_for_void
avoid_shadowing_type_parameters
avoid_single_cascade_in_expression_statements
avoid_types_as_parameter_names
avoid_unnecessary_containers
avoid_web_libraries_in_flutter
await_only_futures
camel_case_extensions
camel_case_types
constant_identifier_names
control_flow_in_finally
curly_braces_in_flow_control_structures
empty_catches
empty_constructor_bodies
empty_statements
exhaustive_cases
file_names
hash_and_equals
implementation_imports
iterable_contains_unrelated_type
library_names
library_prefixes
list_remove_unrelated_type
no_duplicate_case_values
no_logic_in_create_state
non_constant_identifier_names
null_closures
overridden_fields
package_names
package_prefixed_library_names
prefer_adjacent_string_concatenation
prefer_collection_literals
prefer_conditional_assignment
prefer_const_constructors
prefer_const_constructors_in_immutables
prefer_const_declarations
prefer_const_literals_to_create_immutables
prefer_contains
prefer_equal_for_default_values
prefer_final_fields
prefer_for_elements_to_map_fromIterable
prefer_function_declarations_over_variables
prefer_generic_function_type_aliases
prefer_if_null_operators
prefer_initializing_formals
prefer_inlined_adds
prefer_is_empty
prefer_is_not_empty
prefer_is_not_operator
prefer_iterable_whereType
prefer_null_aware_operators
prefer_spread_collections
prefer_typing_uninitialized_variables
prefer_void_to_null
provide_deprecation_message
recursive_getters
sized_box_for_whitespace
slash_for_doc_comments
type_init_formals
unnecessary_brace_in_string_interps
unnecessary_const
unnecessary_getters_setters
unnecessary_new
unnecessary_null_in_if_null_operators
unnecessary_overrides
unnecessary_string_escapes
unnecessary_string_interpolations
unnecessary_this
unrelated_type_equality_checks
use_full_hex_values_for_flutter_colors
use_function_type_syntax_for_parameters
use_key_in_widget_constructors
use_rethrow_when_possible
valid_regexps
void_checks

pedantic_mono で追加されているルール集

pedantic_mono では、flutter_lints のルールに 加えて、下記のルールを採用されています。

always_declare_return_types
always_put_control_body_on_new_line
avoid_bool_literals_in_conditional_expressions
avoid_catches_without_on_clauses
avoid_catching_errors
avoid_classes_with_only_static_members
avoid_double_and_int_checks
avoid_dynamic_calls
avoid_field_initializers_in_const_classes
avoid_implementing_value_types
avoid_js_rounded_ints
avoid_multiple_declarations_per_line
avoid_positional_boolean_parameters
avoid_private_typedef_functions
avoid_returning_null
avoid_returning_this
avoid_setters_without_getters
avoid_slow_async_io
avoid_type_to_string
avoid_unused_constructor_parameters
avoid_void_async
cancel_subscriptions
cascade_invocations
cast_nullable_to_non_nullable
close_sinks
comment_references
deprecated_consistency
directives_ordering
flutter_style_todos
invariant_booleans
join_return_with_assignment
lines_longer_than_80_chars
literal_only_boolean_expressions
no_adjacent_strings_in_list
no_default_cases
null_check_on_nullable_type_parameter
omit_local_variable_types
one_member_abstracts
only_throw_errors
package_api_docs
parameter_assignments
prefer_asserts_in_initializer_lists
prefer_constructors_over_static_methods
prefer_final_in_for_each
prefer_final_locals
prefer_foreach
prefer_int_literals
prefer_interpolation_to_compose_strings
prefer_single_quotes
sort_child_properties_last
sort_constructors_first
sort_pub_dependencies
sort_unnamed_constructors_first
test_types_in_equals
throw_in_finally
tighten_type_of_initializing_formals
type_annotate_public_apis
unawaited_futures
unnecessary_await_in_return
unnecessary_lambdas
unnecessary_null_aware_assignments
unnecessary_null_checks
unnecessary_nullable_for_final_variable_declarations
unnecessary_parenthesis
unnecessary_statements
unsafe_html
use_is_even_rather_than_modulo
use_late_for_private_fields_and_variables
use_named_constants
use_setters_to_change_properties
use_string_buffers
use_to_and_as_if_applicable

まとめ

Linter はコードに秩序をもたらします。秩序はソースコードに安心と信頼をもたらします。パフォーマンス面でも最低ラインをクリアできます。これまで Linter を使っていなかった方にはぜひ導入を検討していただきたいですね。

ちなみに、flutter create my_app で Linter が導入されるのは 2.3.0-12.0.pre 以降です。

この記事執筆時点では、Stable はまだ 2.2.3 なので、チャンネルを変更すれば試してみることができます。

それまでは手動で導入することになりますが、近い将来 Stable にもやってくる、テンプレートの変更に沿って対応するところからスタートしてみてはいかがでしょうか。

ではでは。

すぎっと ٩( ᐛ )و

Discussion