fresh digitable

めんどくさかったなってことを振り返ったり振り返らなかったりするための記録

effective dartを一言ぐらいでまとめていく（Usage編）

dart

続きです：akihito104.hatenablog.com

Usage

Library

複数のファイルに分かれたプログラムを、一貫性のあるメンテナンス可能な方法で構成するのに役立つ。importについてのみ言及しているが、exportディレクティブに対しても応用できる。

  • part ofディレクティブではライブラリ名ではなくURIの文字列を使う（part自体がもうほとんど使われなくなっちゃったけど）。
  • ほかのパッケージのsrcディレクトリの下のファイルをimportしてはいけない。lib/src以下のファイルはパッケージの実装という仕様になっている。
  • libディレクトリの外から相対パスのURIを使ってlib以下のファイルをimportしてはいけない。そのような場合はpackage:でimportする。
  • lib内のファイルをimportする（libをまたがない）場合は相対パスを使うのが好ましい。

Null

  • 変数を明示的にnullで初期化してはいけない。Dartにはuninitialized memoryという概念は無く、暗にnullで初期化される。
  • デフォルト値に明にnullを指定しない。これも暗にnullで初期化される。
  • bool?をboolに変換する際は??を使うのが好ましい。ただし、ifの条件式の中でnull-awareness演算子を使ってbool?をboolにするのは避ける。そのような場合は例えば list != null && list.isEmptyのようにnullチェックをする。
  • 初期化されたかどうかをチェックしたい変数に対してlateを使うのは避ける。Dartではlateの変数が初期化されたかをチェックする方法は提供していない。lateの変数が初期化されたかどうかをboolのフラグによって管理するのは冗長（Dartは内部的にそのように管理している）なので、シンプルにnullableな変数として定義し、nullであるかどうかをチェックする。
  • 型の上位変換を可能にするために、nullableなフィールド変数をローカル変数にコピーすることを検討する。上位変換はローカル変数に対してのみ有効であるため。ただし、コピーした後で値をフィールド変数の方に書き戻す必要がある場合は、忘れずに書き戻すこと。また、フィールドの方の値がスコープの外で更新される可能性がある場合は、単純にフィールド変数を直接使う（!を使って値を取り出す）ことを検討する。

Strings

  • 文字列リテラルを連結するときにはadjusent strings（隣接文字列？）を使う。＋を使う必要はない。長い文章を折り返すのに便利。
  • 文字列と値とを組み合わせるときは内挿を使う。+で連結することもできるけど、内装の方がきれいで手短に済むので好ましい。
  • 内挿を使う時に不要な波カッコを使わないようにする。

Collections

Dartでサポートされているリスト、マップ、キュー、セットについての話題。

  • 可能な時はコレクションリテラルを使う。MapとSetには無名コンストラクタがあるが、便利なビルトインの構文を使った方がよい。
    • 名前付きコンストラクタを使う場合はこの限りではない
    • spread演算子やfor文と組み合わせてコレクションを生成することもできる
  • コレクションが空であるかチェックするときにlengthを使わない。そもそもIterableは長さが分からない。かわりにisEmptyやisNotEmptyを使う。
  • Iterable.forEach()は関数リテラルとともに使わないようにする。ただし、すでにある関数を渡すのは良い（names.forEach(print)のような）。また、MapはIterableではないのでforEach()を使ってよい。
  • 型を変えたいときだけList.from()を使う。単にコピーしたい場合にはtoList()を使う。
  • Listのフィルターを型で行いたい場合はwhereType()を使う。
  • それに近い処理ができる場合にはcast()は使わない。
    • toList().cast()はList.from()で置き換えられる
    • map().cast()はmap<T>()で置き換えられる
  • cast()を避ける。前述のルールをやや一般化する。cast()を使うのが正解であることもあるが、このメソッドがリスキーで思わぬ処理の遅延やケアレスによる実行時の失敗を引き起こすということを考慮しておく。
    • 最初から正しい型を指定する
    • 値を取り出すときにキャストする
    • List.from()を使って即時に変換する。cast()は遅延評価のコレクションを返すので、オペレーションごとに型のチェックを行う。要素も処理も少ない場合には有効だが、多くの場合この遅延評価のオーバーヘッドが重くなる。

Functions

Dartでは関数もオブジェクト。

  • 名前付きの関数を定義するときは関数と名前をバインドする。final func = () => ...ではなく、void func() { ... }のような。
  • tear-offができるときはクロージャを作らない。tear-offとは関数、メソッド、名前付きコンストラクタと同じ引数をとり、呼び出そうとした関数と同じ関数を呼ぶクロージャのこと。Dartではこのtear-offを自動で作るので、わざわざクロージャを書いてラップする必要はない。
  • 名前付き引数にデフォルト値を与えるときは=を使う。過去の経緯から:も使うことができるが、一貫性の観点から=を使うのが望ましい。

Variables

  • 一貫性のあるルールに従ってローカル変数にvarやfinalを付けること。ローカル変数には型アノテーションは付けず、必ずvarかfinalで定義する。次の2つのルールのいずれかが広く使われている。
    • 再代入されないものにはfinalを使い、それ以外にはvarを使う。
    • 再代入されないものであってもvarを使い、finalは一切使わない（フィールド変数やトップレベル変数についてはこの限りではない）。
  • 計算可能な値を保存しないようにする。パフォーマンスの観点でキャッシュする場合にはコメントを付けておくとよい。

Members

Dartではオブジェクトは関数（メソッド）やデータ（インスタンス変数）といったメンバーをもつ。

  • 不必要なgetterやsetterでラップしない。
  • 読み取り専用フィールドはfinalを付けるのが望ましい。
  • シンプルなメンバでは=>の使用を検討する。ただし、2行以上になるものや条件文が複雑なものはブロック形式で記述する。値を返さないようなsetterについても=>を使える。同じく=>を使っているgetterのメンバと対応させるとわかりやすい。
  • 名前付きコンストラクタにリダイレクトしたりシャドウイングを避ける以外の用途でthisを使わない。
  • 可能な場合は宣言時にフィールドを初期化する。

Constructors

  • 可能な場合はinitializing formalsを使う。できない時は仕方ないけどできるときはそうすべき。
  • コンストラクタのリストイニシャライザを使う時はlateを使わない。
  • コンストラクタのボディが空の時は {}ではなく ;を使う。
  • newを使わない。
  • 無駄にconstを使わない。次のようなケースは暗黙的にconstなので書く必要はないし、無駄なので書くべきではない（ただし、デフォルト値については後続のリリースでconstでないものにも対応するのでこのリストには入れていない）。

Error handling

  • on節を使わずにcatchするのは避ける。on節を付けないとtryブロック内で起きたすべての例外をキャッチすることになる。StackOverflowErrorやOutOfMemoryErrorを適切に処理するのは難しいし、意図的に出しているArgumentErrorやassert()の例外を握りつぶすのは本意ではないはず。catchにon節をつけて、自分が認識していて正しく処理できる例外だけをキャッチする。まれに、すべての実行時例外をキャッチしたいという事があるが、そういうものは普通はフレームワークや低レイヤにおいて、それらのコードが原因でプログラムに問題が起きるのを防ぐのに使われる。こうした場合でもすべての例外をキャッチするよりもExceptionだけをキャッチする方がよい。Exceptionはすべての実行時例外の基底クラスである。
  • on節なしでキャッチしたエラーを捨ててはいけない。もしすべてのエラーをキャッチした方がいいと考えるなら、キャッチしたときにログをとったり、ユーザーに知らせたりするべきで、ただ静かに捨てていいものではない。
  • プログラムのエラーのために実装したErrorを投げる。Errorクラスはプログラムのエラーの基底クラス。Exceptionは実行時例外の基底クラス。Exceptionを投げるべきところでErrorを投げるとミスリーディングになるので気を付ける。
  • Errorやその実装型をキャッチしない。Errorはプログラミングのミスなので、プログラムを停止させてスタックトレースを表示し、ミスの原因に立ち返ってこれを修正する。
  • キャッチした例外を投げなおすときはrethrowを使う。rethrowを使うと元のスタックトレースをそのまま保存できるが、throwで投げてしまうと最後に投げた地点でこれがリセットされてしまう。

Asynchrony

  • Futureをそのまま使うよりasync/awaitを使うのが好ましい。非同期のコードはFutureを使ったとしても読んだりデバッグするのは難しいが、async/await構文を使うことで読みやすくできる。
  • 無駄なところでasyncを使わない。便利なのは次のような場合：awaitを使う時（これは自明）、Errorを非同期に返したい時（Future.error()より短く書ける）、値をFutureでラップして返したい時（Future.value()より短く書ける）。
  • ストリームを変換するために高階関数を使うことを検討する。（Iterableに関する上記の議論って何？）
  • Completerを直接使うのは避ける。普通はFutureやasync/awaitで事足りる。Completerは低レイヤのコードにおける次の2つの場合に必要である：非同期のプリミティブを新しく作る時、Futureを使わない非同期のコードのインタフェースに使う時。
  • ObjectであるかもしれないFutureOr<T>の型を解決する際には、まずFuture<T>であるかどうかをチェックする。もしTがintであるなら、FutureOr<int> valueはvalue is intとvalue is Future<int>で見分けられる。しかし、TがObjectである場合、Future<Object>もまたObjectであるのでintの場合のように見分けることができない。