シンプリシティ ―持続可能かつ人間的で効果的なソフトウェア開発

8章コードの現場で

コードフォーマットの話になると、開発者はいろいろとばかげた議論を始める。インデントの文字数をどうするか、開き波括弧は次の行の先頭に置くべきかなどだ。私はそんなことには関心がない。

私が気にするのは、主に2つのことだ。

• 読みやすいか？
• 編集しやすいか？

自分にこれができるだろうか？

• すばやく物事を見つけられるか？
• 一目で構造を把握できるか？
• 影響範囲を最小に留めて、追加や削除ができるか？

ここで話しているのは、コードの設計についてではない。ソースファイルやプログラムコードといった、エディタで実際に目にするものについての話だ。

この章のプラクティスは、私のコードを、私が読みやすく修正しやすくするために、私が行っていることだ。しかし、これは単に私のリストにすぎない。

自分自身のコードに目を光らせておこう。変更を難しくするようなパターンを使っていないだろうか？ コードに目を通していて、探しているものがなかなか見つからないことはないだろうか？ もしそうなら、立ち止まって、次はどうすればもっと明確にできるかを自問してみよう。

プラクティス23ノーコメント

一部の開発者はコメントを書く。大量のコメントを。過剰な数のコメントを。すべてのファイル、すべてのモジュール、すべての関数、すべての変数、そしてすべてのパラメータに、小説のような長いコメントが付いている。そして、すべての型が注釈され、例外が列挙され、命名が問題になった場合に備えて緊急連絡先情報まで記載されている。

Idea 50

コードを読みやすくし、コメントを減らすこと

私の考えでは、コメントは悪しき習慣だ。まず、コードの変更に対して作業が2倍になる。コードを変更すると、関連するコメント文も修正しなければならない。そして、コメントは通常テストされないため、それらのコメントの変更が正しいという保証はない。時間の経過とともに、コメントは負債になっていく。その頃には中身が正確ではないため、誰も信用せず、変更を加える際の足かせとなる。 ...