現状報告
前回投稿したのが、僕の記憶が正しければ確か11月中頃だったと思います。
そして今この文章を書いているのが12月30日です。
年末になってしまいました。そして、2回目の投稿を待つ前にリーダブルコードは読み終わってしまいました。
みなさん、よいお年を。
何かしらのアウトプットはしたい
そんなわけで、もう意味がないと言われたらぐうの音は出ませんが、それでも自分の頭の中に残っているものをできるだけアウトプットしておきたい。それだけのために誰に需要があるかわかりませんが、書き残しておきます。
優しい貴方、お付き合いください。
本題
何できれいなコードを書かないといけないのか？
ソースコードが「書かれる時間」と「読まれる時間」はどちらが長いか？「読まれる時間」の圧勝である。
自分の書いたコードは、その後保守や追加開発を行う人が、どんな処理をしている箇所なのか理解するために、時間を使って読む必要がある。何なら自分で書きながら、その直前に自分で書いたコードを読んで処理の流れを理解する必要がある。
そんな形でいろんな人に何度も何度も読まれるのがコードであるから、それにかかる労力を最小限にするために、きれいで読みやすいコードである必要がある。
十分な情報量で誤解されない名前
コーディングをする際には、変数やメソッドに名前を付ける。その際、それぞれの変数やメソッドが何をする者かが名前を見ただけで理解できるようになっていれば、可読性が格段に上がる。
そのためには、ただ短さにこだわるような名前ではだめ。とりあえず印象に残ってることは↓のような感じ。
・スコープに合わせて変数名を決定
・変数の方やメソッドの内容に合わせて接頭辞や接尾辞を決定
・具体的な名前にして汎用的な名前にしない
無駄を省く
先ほど書いた通り、"コードを読む"ということのコストを削減するという大前提を達成するために、コードは可能な限り短く、無駄の少ないものとすべきである。例えば以下のようなものが無駄とされている。
・不要な中間変数
→結果を返すための値を一時的に格納するためだけに宣言された変数
・ソースで記載したことを日本語にしたコメント
→一番の理想はソースを読んだだけで何をしているかが直感的にわかること。ソースに書いていることをそのまま説明するようなコメントがある場合、単純に読むコストは2倍になる。
コメントに書くべきは、Whyの内容。WhatやHowはコードに含まれるべき。
単純化することに悪はない
処理ロジックを書く際に、小さい部品に分割して単純化していくということによるデメリットはなし。
1つのメソッドには1つの役割しか持たせない。
この原則を守ることによるメリットは多数。
・機能改修時の影響範囲が小さく、改修のハードルが下がる
・メソッド名を見ただけで詳細の処理内容を予測することができ、究極読まなくてもよいということも実現できる
・短いとシンプルに読みやすい
感想
非常に読みやすく、面白くで、なんでもっと早く読んでおかなかったんだろうと過去の自分が雑魚すぎて悲しくなりました。自分が参画しているプロジェクトのソースコードを思い出しながら読むとリファクタリングしたくて仕方ない気持ちにもなりました。
アウトプットとして今回Qiitaに内容の要約を書かせてもらっていますが、その他にも自分の業務の中でコードレビューなどの際でもアウトプットができました。（やたらと細かい部分を指摘してしまった後輩さんよ申し訳ない、、）
本使って勉強するのは久々だったんですが、楽しかったです。味を占めて、また別の本を読み始めてます。
また余裕出来たら、アウトプット用の投稿をしようかと思います。また今度、よいお年を。