Effective Dart

過去数年間、私たちは大量のDartコードを書き、何がうまく機能し、何がうまくいかなかったかについて多くのことを学びました。そのため、皆さんも一貫性があり、堅牢で、高速なコードを書くことができるように、この知識を共有しています。2つの包括的なテーマがあります。

1. 一貫性を保つこと。 フォーマットやキャスティングなどのことに関しては、どちらが良いかという議論は主観的であり、解決することは不可能です。私たちが知っているのは、一貫性があることが客観的に役立つということです。

   2つのコード片が異なって見える場合、それはそれらが意味のある方法で異なっているためであるべきです。コードの一部が際立って目に留まる場合は、それは有用な理由があるからであるべきです。

2. 簡潔にすること。 Dartは馴染みやすいように設計されており、C、Java、JavaScriptなどの多くの言語と同じステートメントや式を継承しています。しかし、私たちはDartを、これらの言語が提供するものには改善の余地がたくさんあるという理由で作成しました。文字列補間から初期化フォーマルまで、意図をよりシンプルかつ容易に表現するのに役立つ多くの機能を追加しました。

   何かを表現する方法が複数ある場合は、一般的に最も簡潔な方法を選ぶべきです。これは、プログラム全体を1行に詰め込むためにコードゴルフをするべきだという意味ではありません。目標は、密度の高いコードではなく、経済的なコードです。

理解を容易にするために、ガイドをいくつかの別々のページに分割しました。

• スタイルガイド – これは、コードのレイアウトと整理のルールを定義します。少なくとも、dart format が処理しない部分です。スタイルガイドは、識別子のフォーマット方法も指定します。camelCase、using_underscores など。

• ドキュメントガイド – これは、コメントに何を含めるべきかについてのすべての情報を提供します。ドキュメントコメントと通常の、ありふれたコードコメントの両方です。

• 使用ガイド – これは、言語機能を使用して動作を実装する最良の方法を教えます。ステートメントまたは式にあるものはすべて、ここでカバーされます。

• デザインガイド – これは最も緩やかなガイドですが、最も広範囲に及びます。ライブラリ向けの、一貫性があり使いやすいAPIを設計することについて学んだことをカバーしています。型シグネチャまたは宣言にあるものはすべて、ここで説明されます。

すべてのガイドへのリンクについては、概要を参照してください。

各ガイドはいくつかのセクションに分かれています。セクションにはガイドのリストが含まれています。各ガイドはこれらの単語のいずれかで始まります。

• DO ガイドは、常に従うべきプラクティスを説明します。それに従わない正当な理由はほとんどないでしょう。

• DON'T ガイドは、その逆です。ほとんど常に良い考えではないことです。幸いなことに、他の言語よりもこれらの数が少ないはずです。なぜなら、歴史的な負債が少ないからです。

• PREFER ガイドは、従うべきプラクティスです。ただし、そうしないことが理にかなる状況があるかもしれません。無視するときは、その含意を完全に理解していることを確認してください。

• AVOID ガイドは、「prefer」の二重です。従うべきではないが、まれに良い理由があるかもしれないものです。

• CONSIDER ガイドは、状況、先例、および自身の好みに応じて、従うべき場合も従わない場合もあるプラクティスです。

一部のガイドでは、ルールが適用されない例外を説明しています。リストされている場合、例外は網羅的ではないかもしれません。他のケースでも、判断力が必要になる場合があります。

これは、靴ひもを正しく結ばないと警察がドアを叩き壊しに来るようなものに聞こえるかもしれません。それほどひどいものではありません。ここのガイドのほとんどは常識であり、私たちは皆合理的な人々です。いつものように、目標は、きれいで、読みやすく、保守しやすいコードです。

Dartアナライザーは、これらのガイドラインやその他のガイドラインに従った、良好で一貫性のあるコードを作成するのに役立つリンターを提供します。ガイドラインに従うのに役立つリンター ルールが1つ以上存在する場合、ガイドラインはそのルールにリンクします。リンクは次の形式を使用します。

リンター ルール: unnecessary_getters_setters

リンターの使用方法については、リンター ルールの有効化とリンター ルールのリストを参照してください。

ガイドを簡潔にするために、さまざまなDart構造を参照するためにいくつかの略語を使用します。

• ライブラリメンバーは、トップレベルのフィールド、ゲッター、セッター、または関数です。基本的に、型ではないトップレベルのものはすべてです。

• クラスメンバーは、クラス内で宣言されたコンストラクタ、フィールド、ゲッター、セッター、関数、または演算子です。クラスメンバーは、インスタンスまたは静的、抽象または具象にすることができます。

• メンバーは、ライブラリメンバーまたはクラスメンバーのいずれかです。

• 変数は、一般的に使用される場合、トップレベル変数、パラメータ、およびローカル変数を指します。静的フィールドまたはインスタンスフィールドは含まれません。

• 型は、名前付き型宣言（クラス、typedef、またはenum）です。

• プロパティは、トップレベル変数、ゲッター（クラス内またはトップレベル、インスタンスまたは静的）、セッター（同上）、またはフィールド（インスタンスまたは静的）です。ほぼすべての「フィールドのような」名前付き構造です。