名著「リータブルコード」を読んで、ためになった2つのこと
はじめに
株式会社SHIFT テスト自動化エンジニアの城間です。
今回は上長に勧めてもらった「リーダブルコード」を読んでの感想と、ためになった章の紹介をしていきます。
対象者
全プログラマーの方が対象です。
また、どのプログラム言語でも共通する内容となっています。
リーダブルコードって？
リーダブルコードは、O’REILLY発行の本で、発売から10年以上経った今でも売れ続けている 「全プログラマ必読書」と言われている本です。
「読みやすいコードを書く」を目的に、様々な実践的なテクニックを紹介しています。
【リーダブルコード】
本を読み終えての感想
もっとシンプルで分かりやすいコードを書きたいが、どう書けばよいか分からず模索していたが一つの指針ができた。
すぐに使える手法が記載されているため、すぐに実践できコーディングのモチベーションが上がった。
思ったより読みやすく、面白かった。
ためになったこと
ここからは、リーダブルコードを読んで特にためになった章を2つ紹介します。
2章 誤解されない名前
名前が「ほかの意味と間違えられることはないだろうか？」と何度も自問自答する。(P.30)
関数や変数の名前は、意味や目的の誤解がない名前付けをする必要があります。そうすることで、読者によって解釈が異なり、誤解が生じるのを防ぐ事ができます。
今回は、2章の中でもすぐ使えそうなテクニックを2つ紹介します。
● 限界値を含めるときはminとmax
● 範囲指定はfirstとlast
限界値を含めるときはminとmax
以下の名前だと、10が上限なのか下限なのかが明確にわかりません。
const LIMIT_ITEM_IN_CART = 10この場合は、「MAX_ITEM_IN_CART」とすることで、10が上限だと分かり、誤解のない名前付けをすることができます。
下限の場合は「min」を使用しましょう。
範囲指定はfirstとlast
以下のコードだと指定範囲が0～1なのか0～2なのか明確にはわかりません。
startは適切な名前ですが、stopは複数の意味に解釈できてしまうからです。
const start = 0
const stop = 2
integerRange(start, stop)firstとlastを使うことで、定義されている2は包括内だとわかり、指定範囲が0～2であると変数名を見ただけで理解できるようになります。
const first = 0
const last = 2
integerRange(first, last)以上のことから範囲や限界値を指定する際は、指定範囲(以下なのか未満なのか)が明確に理解できる命名にすることが奨められています。
2章の感想
私は名前を付けるとき、google翻訳で翻訳して出てきた単語をそのまま使ってしまうことがありましたが、この章を読んで、英単語のニュアンスをしっかり調べ、本当にこの英単語がベストであるのか何度も自問自答するようになりました。
5章 コメントすべきことを知る
コメントを読むと、その分だけコードを読む時間がなくなる。コメントは画面を占領してしまう。 言い換えれば、コメントにはそれだけの価値を持たせるべきなんだ。 (P.57)
この章では何をコメントすべきなのかについて解説しています。
コメントすべきではないこと
コメントすべきこと
コメントすべきでないこと
コードからすぐに推測できること
以下のようにコードからすぐに推測できることにはコメントはいりません。
//userIdを取得する
getUserId()ただ、この「すぐに」が重要で、以下の場合はコードから動きは推測できますが、コードを理解するよりコメントを読むほうが早く理解できます。
//2番目の"!"以降をすべて削除する
name = "!".join(line.split("!")[:2])この場合は、コメントを書くと読み手に親切でしょう。
ひどいコードを補う補助的なコメント
わかりずらいコード(例えば、わかりずらい名前の関数)を補う「補助的なコメント」は、コードを修正して、コメントは削除しましょう。
//名前を取得する
get()↓
getName()「優れたコード＞ひどいコード＋優れたコメント」 (P.60)
コメントすべきこと
自分の考えを記録する
なぜコードがほかのやり方ではなくこうなっているのか等、 コードを書いているときに持っている「大切な考え」をコメントで残しましょう。
//このデータだとハッシュテーブルより、バイナリツリーの方が40%早かった
//左右の比較より、ハッシュ計算コストのほうが高いようだ。この例では、コメントから情報を得ることで、最適化しようとして無駄に時間を使うことを防ぐことができます。
コードの欠点にコメントを付ける
改善が必要なコードには下記のようにコメントを付けましょう。
そうすることで、コードの品質や状況を知らせたり、さらには改善の方向を示したりできます。
//TODO: txt以外のフォーマットに対応する定数にコメントを付ける
定数にはなぜその値を設定したのか「背景」が存在する場合が多いです。
その「背景」を説明するためにコメントをつけましょう。
//0.72ならユーザはファイルサイズと品質の面で妥協できる
IMAGE_QUALITY = 0.72このようにコメントを残すことで、なぜその値なのかを知らせることができます。
要約コメント
コード量が多い場合、途中でコードの理解が追いつかなくなってしまうことがあります。
読み手が理解しやすいよう、コードブロックに要約コメントを付けましょう。
GenerateUserReport(){
// ユーザーのロックを獲得する
{...}
// ユーザー情報をDBから読み込む
{...}
// 情報をファイルへ書き出し
{...}
// このユーザーのロックを解放する
{...}関数の処理を箇条書きでまとめたものなので、詳細を調べなくても関数の概要が把握できるようになっています。
5章の感想
自分のコードを見返したときに、結構「コードからすぐに推測できること」にコメント付けてたな～と反省しました。
まとめ
誤解されない名前
関数や変数の名前は、意味や目的の誤解がない名前付けをする
限界値を含めるときはminとmax
範囲指定はfirstとlast
コメントすべきことを知る
コメントすべきではないこと
コードからすぐに推測できることはコメントしない
ひどいコードを補う「補助的なコメント」はコードを修正
コメントすべきこと
自分の考えを記録する
コードの欠点にTODO:コメントを付ける
定数にまつわる「背景」のコメントを付ける
コードブロックごとに要約コメントを付ける
さいごに
リーダブルコード良いです。
読んだらコードを書く時の考え方も変わってくると思います。まだ読んでいない方はぜひ読んでみてください。
執筆者プロフィール：城間 栄樹
前職では3年ほど保守開発を経験。2021/11/01 SHIFTにテスト自動化エンジニアとして入社。
【趣味】サウナ、登山
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/