脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック

付録Aプラクティス一覧

この付録には本書で紹介したさまざまな手法と経験則をどこで参照できるかを含めてまとめています。

A.1　50/72ルール

慣例を踏まえたコミットメッセージを書きましょう。

• サマリーを命令形で書く。50文字以上にしない†1
• さらに書く場合は、次の行を空行にする
• 好きなだけ追加のテキストを書いてよいが、横幅が72文字を超えないようにフォーマットする

サマリー以外は、なぜその変更をするのかの説明を中心にします。Gitのdiffを使えば変更に何が含まれるのかはわかるからです。詳細は9.1.1を参照してください。

[†1] 訳注：日本語の場合は現在形で表現し、半分程度の文字数を目安とするのがよいでしょう。

A.2　80/24ルール

小さなコードブロックを書きましょう。

C#やJava、C++、JavaScriptのようなCをベースにした言語であれば、80文字、24行の箱に収めるようにしてください。これは古いターミナルウィンドウのサイズと同じです。

80文字、24行のしきい値を絶対的な数字としてとらえる必要はありません。この数字にした理由は3つです。

• 実際にうまくいく
• 伝統の継続性
• 覚えやすさ。80/20ルールとして知られるパレートの法則に似ている

他のしきい値にしても構いません。このルールでいちばん重要なのは、しきい値を設定して、その制限に収まるようにし続けることです。

詳細は7.1.3を参照してください。

A.3　Arrange-Act-Assert

Arrange-Act-Assertのパターンに従って自動テストを構造化しましょう。どこでセクションが終わって、新しいセクションが始まるかを読み手がわかるようにしてください。解説は4.2.2、詳細は4.3.3 ...