1. Dartは「自由を与えない」ことで成立している
Dartの設計思想を一言で言うなら、制約による事故防止です。
・暗黙の型変換を極力させない
・条件式に曖昧さを残さない
・nullを例外ではなく仕様として扱う
これは個人開発向けではなく、中〜大規模開発を前提とした言語設計です。
書き手のセンスに依存しないコードを量産するための選択です。
2.実行モデルとmain()が担う責務
Dartではmain()は単なる開始点ではありません。
ここは以下の責務を担います。
・初期化の順序を確定させる
・グローバルな状態の境界を決める
・非同期処理の起点になる
特にFlutterでは、mainを軽視すると初期化タイミング地獄に入ります。
3.型は制約ではなく情報密度
Dartにおいて型は「縛り」ではありません。この宣言だけで、読み手は次を理解できます。
・nullではない
・小数にならない
・数値演算を前提としている
varは便利ですが、情報を削る行為でもあります。Dartで型を書くことは、コードに意味を埋め込む作業です。
4. 条件分岐とループが厳密な理由
Dartでは以下が禁止されています。
これは意地悪ではありません。「trueとは何か」を曖昧にさせないためです。
Dartは意図をコード上に固定させることを優先します。この思想はレビュー耐性を大きく上げます。
5. 関数設計：処理を書く前に決めること
Dartの関数で最初に決めるべきはロジックではありません。
この時点で、
・入力の形
・出力の保証
・例外の扱い
がほぼ確定します。
型を書かない関数は、責務を宣言していない関数です。
6. コレクション型と状態の持ち方
Dartの List や Map は可変です。
ここで重要なのは、
・参照は固定
・中身は変更可能
という点です。
この中途半端さが、状態管理を難しくします。Dartは完全な不変よりも制御可能な可変を選んだ言語です。
7. クラス設計で壊れる境界
Dartで最も壊れやすいのは、状態を持つクラスです。
この設計では、
・変更点が追えない
・テストが不安定
・状態管理と衝突
が起こります。
Dartは状態を固定する設計を前提にしています。
8. null安全は設計判断の可視化
null安全は便利機能ではありません。
これは「この値は存在しない可能性がある」という設計判断の明示です。安易な ? は設計放棄に近く、後で必ず複雑さとして返ってきます。
9. Dartのコーディングスタイルは最適化の結果
Dartのスタイルは厳格です。
・自動フォーマット前提
・静的解析前提
・コード生成前提
つまり、人間の好みではなくツール連携の最適解です。逆らう理由はありません。
10. JavaScript / Javaとの思想的差分
DartはUIと状態管理のために設計された言語です。
Dartは学習コストを前払いさせる言語です。その代わり、後半で破綻しにくい設計が手に入ります。1日でやるべきことは、構文を覚えることではなく、Dartが何を禁止し、何を守ろうとしているかを理解することです。そこを越えれば、Dartは一貫して扱いやすい言語になります。
