事故は現場で起きているんだ

システムエンジニアの奮闘記

より良いコードを書く、リーダブルコード

最近やってるプロジェクトではPythonを使っている。
そのプロジェクトがWEB系ではないので、自作でフレームワークを作成し、そのフレームワークをチームメンバーで利用することにした。
フレームワーク作成時に悩んだのが大きく2つあった。

  • クラスの構造
  • 名前(クラス、メソッド、変数…)

「名前なんかなんでもいいじゃ!」と思うかも知らないけど、チームで開発するには結構大事なんだ、その名前が…
それに、参考にしたのが「リーダブルコード」

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

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

この本が教えてくれる考え方を章ごとに整理。 ※リストになっている箇所は「鍵となる考え」、リストになっていない箇所はそれ以外で良いと思ったこと、気付いたことである。

リーダブルコード

1章 理解しやすいコード

  • コードは理解しやすくなければいけない。
  • コードは他の人が最短時間で理解できるように書かなければいけない。

2章 名前に情報を読め込む

  • 名前に情報を詰め込む。

いい名前というのは、変数の目的や値を表すものだ。
識別子のスコープが大きければ、名前に十分な情報を詰め込んで明確にする必要がある。
プロジェクトで一貫性を持たせることが大切だ。

3章 誤解されない名前

  • 名前が「他の意味と間違えられることはないだろうか?」と何度も自問自答する。

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

4章 美しさ

  • 一貫性のあるスタイルは「正しい」スタイルよりも大切だ。

読み手が慣れているパターンと一貫性のあるレイアウトで使う。
似ているコードは似ているように見せる。
関連するコードをまとめてブロックにする。

5章 コメントすべきことを知る

  • コメントの目的は、書き手の意図を読み手に知らせることである。
  • コードからすぐにわかることをコメントに書かない。

読み手の立場になって考える。
質問されそうなことを想像する。

コメントを書く3つの簡単な手順

  1. 頭のなかにあるコメントをとにかく書き出す。
  2. コメントを読んで(どちらかと言えば)改善が必要なものを見つける。
  3. 改善する。

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

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

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

  • 条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く。
  • 行数を短くするよりも、他の人が理解するのにかかる時間を短くする。
  • 変更するときにはコードを新鮮な目で見る。一歩下がって全体を見る。

条件は否定形よりも肯定形を使う。
単純な条件を先に書く。
関心を引く条件や目立つ条件を先に書く。

8章 巨大な式を分割する

  • 巨大な式は飲み込みやすい大きさに分割する。

9章 変数と読みやすさ

  • 変数のことが見えるコード行数をできるだけ減らす。
  • 変数を操作する場所が増えると、現在値の判断が難しくなる。

タスクはできるだけ早く完了するほうがいい。

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

関数というのは、小さくて独立したものになっていれば、機能追加・読みやすさの向上・エッジケースの処理などが楽にできる。

11章 一度に1つのことを

  • コードは1つずつタスクを行うようにしなければいけない。

タスクを分割すると、コードのことを考えやすくなる。

12章 コードに思いを込める

おばあちゃんがわかるように説明できなければ、本当に理解したとは言えない。
--- アルバート・アインシュタイン

問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になっていないということだ。

13章 短いコードを書く

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

たまには標準ライブラリのすべての関数・モジュール・型の名前を15分かけて読んでみよう。
ライブラリを全部覚えろと言ってるわけじゃない。どんなことができそうか感じ取るだけでいい。
不必要な機能をプロダクトから削除する。過剰な機能は持たせない。
最も簡単に問題を解決できるような要求を考える。
定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく。

14章 テストと読みやすさ

  • 他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
  • コードを完全にテストする最も簡単な入力値の組み合わせを選択しなければいけない。
  • テストには最もキレイで単純な値を選ぶ。

一般的な設計原則として、「大切ではない詳細はユーザから隠し、大切な詳細は目立つようにする」べきだ。
テストの本質というのは、「こういう状況と入力から、こういう振る舞いと出力を期待する」のレベルまで要約できる。

おわりに

本は15章まであるが、15章はおまけであるため、実際に読んだ方がいいと思う。
いろいろ「考えさせる」本なので、結構なところで役に立つ。
ま、自分にネーミングセンスが欲しいというところには変わりがないけどな。。。
また頑張ろうぜ!!