読者です 読者をやめる 読者になる 読者になる

「リーダブルコード」を再び読んだ

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

発売当初に読んだが、再び読んでみた。

TL;DL

「自分のコードを他人が読んだ時、理解するまでの時間が最短になる為のコーディング手段」を提示してくれる。今後も色褪せない良書であり、プログラマであれば、読むべき書だと思う。

Readableの定義

コードは他の人が最短で理解できるように書かなければならない

以下、各章で気になった言葉をメモしていく

2. 名前に情報を詰め込む

直行する概念は無理に1つにまとめようとせずに、別々に使えるようにするといい

3. 誤解されない名前

最善の名前とは、誤解されないものである。

4. 美しさ

間違ったスタイルであろうと、プロジェクトの規約に従う。
一貫性のあるスタイルは「正しい」スタイルよりも大切だ。

5. コメントするべきでは「ない」こと

コードからすぐに分かることをコメントに書かない。

6. コメントは正確で簡潔に

コメントは領域に対する情報の比率が高くなければならない。

7. 制御フローを読みやすくする

行数を短くするよりも、他の人が理解するのにかかる時間を短くする。

8. 巨大な式を分割する

「頭がいい」コードに気を付ける。あとで他の人がコードを読むときにわかりにくくなる。

9. 変数と読みやすさ

  • クラスのメンバへのアクセスを制限する方法
    • scopeは短く
    • メソッドを出来るだけstaticに(メンバ変数とは関係ないことが分かる)
    • 大きなクラスを小さなクラスの分割する
      • 但、分割後のクラスが独立していれば問題ないが、クラスで相互にメンバを参照し合うようなら分割しても意味がない
    • そもそも、一度だけ書き込む変数を使う、immutableに

10. 無関係の下位問題を抽出する

  • 無関係の下位問題を積極的に探し出して、分離する
    • プロジェクト固有のコードから汎用コードを分離する(Util関数のライブラリ化)

13. 短いコードを書く

最も読みやすいコードは、何も書かれていないコードだ。

14. テストと読みやすさ

  • テストを読みやすくする、一般的な設計原則として
    • 大切でない詳細はユーザから隠し、大切な詳細は目立つようにする

まとめ

目標かつ日々意識することを忘れたり、ぶれたりするような事があった際に、
この本に立ち返りたいと思う。

See also