【読書】リーダブルコード読みました
はじめに
ずっと読もうと思っていた
リーダブルコードを読んだので、
響いたことを、自分なりに咀嚼してつらつらと書きます！
この記事の【ポイント】部分は、
ほぼ自分への戒めです。
今までの自身の愚かなコードを振り返りつつ…
振り返るほどコーディングの経験ないけども。
命名
脇役的な変数にも愛を持って命名する
念のために定義しておこう～いらなかったら消そう～
と思って、適当な変数定義して、
結局消さずに居座られるあるある
置換もめんどくて、そのままにしちゃうあるある
tmp_hogehogeとか気を抜くと使ってしまう気がします。
というか、中間結果を保持するだけの変数は、
乱立させないように気をつけます。
【ポイント】
tmpという文字列も「一時的」とか意味を持つので、適当に使わない- 変数を無駄に増やさない
その関数にはどんな動作が期待される？
コードを読む側の先入観を想定して書くと、
より読みやすくなるとのことです。
書き手としては意識したことなかったですが、
読み手的にはGet…()みたいな関数は、
メンバの値を返すだけの軽めの関数かなぁと期待します。
確かにGet…()が何十行にわたる重厚なコードだったら萎えますね。
【ポイント】
- 関数は、読み手が期待する動作(のレベル感)を想像して命名する
コメント
無駄なコメント削減
心配性なもので、
明日には記憶喪失になってたらどうしようと思い、
やたら細かくコメントしてしまいます。
ただ、コメントが無駄に多いのもスマートさに欠けるし、
見た目から読む気を削ぎますよね。
【ポイント】
- コード見ればわかることはコメントしない
- コメントしなくて済むような命名を意識する
#〇〇を定義とかやめよう。。
意図を記録する
記憶喪失まではいかなくても、
やたら凝ったコード書いて、
翌週、え、私何がしたくて、こんなコード書いたの…
ってなることはあります。
そんなときのためにも、
「意図」をコメントとして残すのは大事です。
【ポイント】
- 何を思ってそのコードを書いたのか、コメントに残す
- 夢中になって書いた傑作コードほど、未来の自分のために書き残す
コードの手段ではなく目的を書く
例えば、
古いメッセージを削除するために、
メッセージ一覧を取得して、最古メッセージIDを特定して、delete実行する。
とか、そんな処理があったとしたら、
コメントするべきなのは、
メッセージ一覧を取得して、最古メッセージIDを特定して、delete実行する。
ではなく、
古いメッセージを削除
がベター、ということですかね。
目的を書いておけば、
第三者が見たとき、「え、この目的達成できてなくね？」
ってなった時に、バグが発覚できるので、
救われる命があるかもしれませんね。
【ポイント】
- 目的が書いてあれば、第三者がレビューしやすいかも
関数の切り出し方
書籍で述べていることを簡潔にまとめると、
読み手をコード全体を通した目標に集中させるために、
目標に直接的に関係ない部分を
積極的に関数化しましょと言っています。
コードも読みやすくなるし、
メンテもしやすくなるります。
【ポイント】
- 関数の切り出し観点
- コード全体を通した目標に直接関係ない
- 汎用的で、使いまわせそう
- やりすぎない笑(調子に乗って、関数作りすぎても逆に見づらい)
おわりに
コーディング歴は半年くらいの雛鳥なので、
行き当たりばったりで書いていることが多く、
なかなか刺さりました。
もう少し経験積んだら、
読む観点も変わってくるのかなと感じました。
定期的に自戒のために、読み続けたい名著です。
