「リーダブルコード」すぐ使える要点まとめ

はじめに

本記事では、「リーダブルコード」を読んで、個人的に業務に活用しやすいと感じた部分を要点として整理してみました。

業務上コーディングをする機会が増えてきた、あるいはコードレビューすることになった方などにおすすめです。

どんな本なのか？

プログラミングをするうえで、機能要件には影響しないけれど、保守性や拡張性には大きく寄与する、コードの可読性という点にフォーカスを当て、これを向上させるための実践的なテクニックを分かりやすく教えてくれます。

コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。

要点PickUp！

理解しやすいコード

優れたコードとは「理解しやすいコード」のことである。
そのためには、基本的にはプログラムは長いより短いほうが良いといえる。
しかし、肝心なのはあくまでも理解の速さであるため、必ずしも短く、簡潔なコードが正義であるとは限らない。

「理解しやすいコード」を書くためには、他人が自分の書いたコードを読んだときどんな気持ちになるか、想像することが大切である。（他人というのは半年後の自分も対象だ！）

名前に情報を詰め込む

明確な単語を選ぶ

メソッド名として採用されがちなgetやsizeは実は明確な単語ではない。

• get
  • 何をとってくるのか？
  • どこからとってくるのか？
  • どのようにとってくるのか？
• size
  • 何を返すのか？
  • 高さを返すのか？
  • 量を返すのか？

getについては、例えば画像を取得するのであればdownloadやfetchのほうが明確だといえる。
また、sizeにおいても、高さを取得するならheight、通信料を取得するならbytesのほうが適切だろう。

汎用的な名前を避ける

temp、retval、fooのような汎用的な名前をなるべく避け、変数の値を表すような名前を使おう。
ただし、こういった汎用的な名前が適切となる場面もある。

if(right < left){
    temp = right
    right = left
    left = temp
}

上記の例ではtempという一時的な値を指す命名が適切だ。

名前の長さを決める

メソッドやクラス、変数に命名するとき、うんざりするほど長い名前になってしまった経験はだれしもあるはずだ。
しかし、往々にしてわざと長くしているようなケースはほとんどなく、必要と思える情報を盛り込んだ結果、長くなってしまうのが悩ましいポイントである。

そんな悩みを解決するためのガイドラインが以下である。

• スコープが小さければ短い名前にする

  • たとえばあるif文やfor文の中でだけ使われるような名前は思い切って短くしてよい
  • 逆に、クラス変数やグローバル変数についてはスコープが広いため、十分な情報を詰め込む必要がある

• 長い名前を入力するのは問題ではない

  • 今どきのエディタには大概優秀な補完機能がついているので、たとえやむを得ずちょっと長い命名をしてしまっても、大した問題は起きない

• 使っていい省略形とだめな省略形
  世間一般に伝わるような省略は良いが、プロジェクトや業務固有の省略形はNG

  • OK
    • evaluation→ eval
    • document→ doc
  • NG
    • BackEnd→ BE

• 不要な単語は削る

  • ConvertToString→ToString
  • DoServeLoop→ServeLoop

誤解されない名前

filter()

フィルタリング条件対象を「除外」するのか？「選択」するのか？
前者であればexclude()、後者であればselect()にしたほうがいい。

限界値を含めるときはminとmaxを使う

• min_limit
• max_items

範囲を指定するときにはfirstとlastを使う

また、包含/排他的範囲にはbeginとendを使う

ユーザの期待に合わせる

get()やsize()には軽量なメソッドが記載されているため、複雑な処理の場合はそれにあわせた命名をすること

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

コメントすべきでないこと

• コードを見たらすぐ分かること
• コードを補足するコメント
  • コードが不十分ならコード自体を見直そう

コメントすべきこと

• コードを書いているときの感想
• コードの欠陥
  • TODO:,FIXME:,HACK:,XXX:を活用する
• 定数の設定背景
• 読み手が疑問に思いそうなこと
• 要約コメント

コードを書きながらとにかく思いついたことはなんでもコメントして、最後に改善する、あるいは不要であれば削除するやり方がおすすめ

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

条件式の並び順

if文などで比較を行うとき、左側に「調査対象」の式を、右側にあまり変化しない「比較対象」の式をもってくることで、普段使っている言語の様式と近くなり読みやすくなる。

• 正しい例

// 左側に調査対象の変数がある
if(length >= 10)

• 悪い例

// 左側に比較対象の定数がある
if(10 <= length)

if/elseブロックの並び順

• 条件は否定形よりも肯定形を使う

if(!debug)
// ではなく
if(debug)

• 単純な条件を先に書く
• 関心を引く条件や目立つ条件を先に書く

上記の優劣は衝突することがある。状況によって適切な判断をしよう

あまり使うべきでない（慎重に使うべき）構文

• 三項演算子
• do/whileループ
• goto

ネストを浅くする

関数で複数のreturn分を使って早く返すことは悪いことじゃない。むしろ、頭の中に覚えておく情報が減っていくので積極的に返していくべきである。

まとめ・感想

本書に記載されているテクニックはほとんど明日から使えるようなものばかりでした。
内容も特に前半はむずかしいものも少なく、初級者～中級者くらいの方なら誰しも勉強になると思います。
ただし、簡単な構文ではあるもののjava,C＃,javascript,pythonなど様々な言語で例文が書かれているので触ったことのない言語の理解には少しとまどうかもしれません。（逆にこの言語がわからないと読みずらい、なんてこともありません）

本記事に書いた内容はあくまでも極一部ですので、興味があるかたは是非読んでみてください！
（ちなみに本書は電子版がamazonからは発売していないので物理本を買いました。。）

最後に、本記事の内容についてご指摘、ご質問などありましたら、コメントいただけると嬉しいです。

以上、ご覧戴きありがとうございましたmm