Contents
Effective Dart
Over the past several years, we’ve written a ton of Dart code and learned a lot about what works well and what doesn’t. We’re sharing this with you so you can write consistent, robust, fast code too. There are two overarching themes:
過去数年にわたって、私たちは大量のDartコードを作成し、何がうまく機能し、何が機能しないかについて多くのことを学びました。 これを共有しているので、一貫性があり、堅牢で、高速なコードも記述できます。 2つの包括的なテーマがあります。
1.Be consistent. When it comes to things like formatting, and casing, arguments about which is better are subjective and impossible to resolve. What we do know is that being consistent is objectively helpful.
一貫性を保つ。 フォーマットや大文字小文字の区別などに関しては、どちらが優れているかについての議論は主観的であり、解決することは不可能です。 私たちが知っていることは、一貫性を保つことが客観的に役立つということです。
If two pieces of code look different it should be because they are different in some meaningful way. When a bit of code stands out and catches your eye, it should do so for a useful reason.
2つのコードが異なって見える場合は、意味のある方法で異なっているためです。 少しのコードが目立ち、目を引くときは、便利な理由でそうする必要があります。
2.Be brief. Dart was designed to be familiar, so it inherits many of the same statements and expressions as C, Java, JavaScript and other languages.
簡潔であること Dartは親しみやすいように設計されているので、CやJava、JavaScriptなどの言語と同じ文や式を多く受け継いでいます。
But we created Dart because there is a lot of room to improve on what those languages offer.
しかし、それらの言語が提供するものには改善の余地がたくさんあるため、私たちはDartを作りました。
We added a bunch of features, from string interpolation to initializing formals, to help you express your intent more simply and easily.
私たちは、文字列補間からフォーマルな初期化まで、よりシンプルに、より簡単に意図を表現できるよう、様々な機能を追加しました。
If there are multiple ways to say something, you should generally pick the most concise one.
複数の表現方法がある場合、一般的には最も簡潔なものを選ぶべきです。
This is not to say you should code golf yourself into cramming a whole program into a single line. The goal is code that is economical, not dense.
これは、1行にプログラム全体を詰め込むようなコードゴルフをしろと言っているのではありません。目指すべきは経済的なコードであり、密なコードではありません。
コードゴルフはコンピュータプログラミング・コンテストの一種。参加者は与えられたアルゴリズムを、可能な限りもっとも短いソースコードで記述することを競う[1]。
The Dart analyzer has a linter to help you write good, consistent code. If a linter rule exists that can help you follow a guideline, then the guideline links to that rule. Here’s an example:
Dart アナライザーは、一貫性のある良いコードを書くためにリンターを備えています。ガイドラインに従うことを支援するリンターのルールが存在する場合、ガイドラインはそのルールにリンクします。以下はその例です。
Linter rule: prefer_collection_literals
For help on enabling linter rules, see the documentation for customizing static analysis.
リンタールールを有効にするためのヘルプは、静的解析のカスタマイズのドキュメントを参照してください。
The guides
We split the guidelines into a few separate pages for easy digestion:
ガイドラインの概要を示すために、いくつかのページに分けています。
- Style Guide – This defines the rules for laying out and organizing code, or at least the parts that dart format doesn’t handle for you. The style guide also specifies how identifiers are formatted:
camelCase,using_underscores, etc.
コードのレイアウトや整理のルール、少なくともdart formatが扱わない部分について定義します。スタイルガイドでは、キャメルケースやアンダースコアの使用など、識別子をどのようにフォーマットするかも指定されています。
- Documentation Guide – This tells you everything you need to know about what goes inside comments. Both doc comments and regular, run-of-the-mill code comments.
コメントの中身について知っておく必要があることは、これですべてわかります。docコメントと普通のコードコメントの両方です。
- Usage Guide – This teaches you how to make the best use of language features to implement behavior. If it’s in a statement or expression, it’s covered here.
使用法ガイド – これは、動作を実装するために言語機能を最大限に活用する方法を教えてくれるものです。ステートメントや式の中にあるものなら、ここでカバーされています。
- Design Guide – This is the softest guide, but the one with the widest scope. It covers what we’ve learned about designing consistent, usable APIs for libraries. If it’s in a type signature or declaration, this goes over it.
これは最もソフトなガイドですが、最も広い範囲をカバーするものです。ライブラリのための一貫した、使いやすいAPIを設計するために学んだことをカバーしています。もし、型名や宣言の中にあるのなら、ここにあります。
How to read the guides
Each guide is broken into a few sections. Sections contain a list of guidelines. Each guideline starts with one of these words:
各ガイドは、いくつかのセクションに分かれています。セクションには、ガイドラインのリストが含まれています。各ガイドラインは、以下のいずれかの単語で始まります。
- DO guidelines describe practices that should always be followed. There will almost never be a valid reason to stray from them.
常に従うべき慣習を記述したものです。そこから外れる正当な理由はほとんどないでしょう。
- DON’T guidelines are the converse: things that are almost never a good idea. Hopefully, we don’t have as many of these as other languages do because we have less historical baggage.
Doの逆で、ほとんど良いアイデアとは言えないものです。願わくば、他の言語に比べて歴史的経緯が浅いので、このようなガイドラインがあまりないことを祈ります。
- PREFER guidelines are practices that you should follow. However, there may be circumstances where it makes sense to do otherwise. Just make sure you understand the full implications of ignoring the guideline when you do.
あなたが従うべき慣行ですが、そうしない方が理にかなっている状況もある場合です。ただし、その場合はガイドラインを無視した場合の影響を十分に理解しておいてください。
- AVOID guidelines are the dual to “prefer”: stuff you shouldn’t do but where there may be good reasons to on rare occasions.
「PREFER」と同じ役割です。すべきではないことですが、まれに正当な理由がある場合もあります。
- CONSIDER guidelines are practices that you might or might not want to follow, depending on circumstances, precedents, and your own preference.
CONSIDERガイドラインは、状況や前例、自分の好みによって、従ったほうがいい場合とそうでない場合がある慣習です。
Some guidelines describe an exception where the rule does not apply. When listed, the exceptions may not be exhaustive—you might still need to use your judgement on other cases.
一部のガイドラインでは、ルールが適用されない例外について説明しています。 リストされている場合、例外はすべてを網羅しているわけではない可能性があります。他のケースについてはあなた自身で判断を下す必要がある場合があります。
This sounds like the police are going to beat down your door if you don’t have your laces tied correctly.
これではまるで、靴紐を正しく結ばないと警察に踏み込まれるような感じを受けるかもしれません。
Things aren’t that bad. Most of the guidelines here are common sense and we’re all reasonable people. The goal, as always, is nice, readable and maintainable code.
物事はそんなに悪いものではありません。ここにあるガイドラインのほとんどは常識的なもので、私たちは皆、合理的な人間なのです。目標は常に、読みやすく、保守しやすい素敵なコードです。
Glossary(用語)
To keep the guidelines brief, we use a few shorthand terms to refer to different Dart constructs.
ガイドラインを簡潔にするため、異なるDartの構成要素を参照するためにいくつかの略語を使用します。
- A library member is a top-level field, getter, setter, or function. Basically, anything at the top level that isn’t a type.
ライブラリメンバとは、トップレベルのフィールド、ゲッター、セッター、関数のことです。基本的には、トップレベルのもので型でないものを指します。(結局、クラスメンバー以外、という事だと思われる。)
- A class member is a constructor, field, getter, setter, function, or operator declared inside a class. Class members can be instance or static, abstract or concrete.
クラスメンバとは、クラス内部で宣言されたコンストラクタ、フィールド、ゲッタ、セッタ、関数、演算子のことです。クラスメンバには、インスタンスとスタティック、抽象クラスもコンクリートクラスがあります。
- A member is either a library member or a class member.
memberはライブラリメンバーかクラスメンバーのどちらかです。
- A variable, when used generally, refers to top-level variables, parameters, and local variables. It doesn’t include static or instance fields.
variable(変数)は、一般的に使われる場合、トップレベル変数、引数、ローカル変数を指します。スタティック(静的)フィールド、インスタンスフィールドは含まれません。
- A type is any named type declaration: a class, typedef, or enum.
type(型)は、名前を付けられた型宣言です。クラス、typedef((主にコードの書き手の意図などを読み手にわかりやすく伝えるために)関数を型として宣言すること)、enum(列挙型)です。
- A property is a top-level variable, getter (inside a class or at the top level, instance or static), setter (same), or field (instance or static). Roughly any “field-like” named construct.
プロパティは、トップレベルの変数、ゲッター（クラス内部またはトップレベルのインスタンスまたは静的）、セッター（同じ）、フィールド（インスタンスまたは静的）です。大雑把に言うと、「フィールドのような」命名された構成要素です。
参考