リーダブルコードを読んでみた

当社ではスキルアップ補助金という制度があり、月1万円まで自分が勉強してみたいと思った内容に対して補助金の手当があります。勉強のためのサーバ費用だったり技術書・ビジネス書、勉強会だったりと結構自由度が高い制度です。

私は今まで本を読む機会がすごく少なかったのですが、この制度のおかげで本をよく読むようになりました。
その中で前々から有名だけどそのうち…と思ってスルーしてきた「リーダブルコード」を今回読んでみましたので、内容に対して感想を書いてみました。

この本を読んでみようと思った理由

今回この本を選択した理由として、

１．相手に理解されやすい（読みやすい）コードを書くことによって引き継ぎ業務等でさらなる効率化が図れると思ったため
２．人に見られて恥ずかしくないコードを目指したいと思ったため
３．独学で勉強した期間が長いため自分のコードの答え合わせをしたかったため
４．有名本なので一度目を通しておきたかったため

となります。

特に可読性の高いコードを意識することは数カ月後自分自身が見直した際にも有効なことが多いです。

名前に情報を詰め込む ／ 誤解されない名前

名付けの話になるのですが、変数名や関数名についてはぱっと見てその変数（関数）が何をやるのかどんな情報が入っているのがすぐに把握できる名前を付けるに限ります。

最近でこそ、まぁこんなもんだろとイメージと経験則で名付けができてますが、私はこの名付けがけっこう苦手です。今でもたまにうーんどうしよと悩んでしまうことは少なからずあります。
特に似たような機能が重なったときですね。
「うーん、こっちは検索で使うからsearchかな？すべて取得してくるからAllを名前に入れようか？あー、でもこの名前こっちの変数で使ってるしなぁ」といった具合です。
あとはキャメルケースでいくかスネークケースでいくかといったことも地味に悩んだりします。

コードレビューをして頂いているときに、もうちょっとこういう変数名のほうがいいのでは？といったご指摘はよくいただきました。

この章で紹介されている内容を要約すると、

１．明確な単語、具体的な名前を使い、汎用的な単語は避ける。
２．名前に情報を追加する。
３．誤解されない名前にする。

こちらの３点かなと思います。
流石に本に記載されていたStop、Kill、Size、Getといっただけの変数名等を使うことはありませんが、ループイテレータなどはついつい癖で「i」「j」「k」といった形で書いてしまうことはよくあります。
暗黙的にこれはイテレータだろうってだいたいのエンジニアは把握してくれますが、これも複数存在するときは不具合の温床になりやすいので具体的な名前を付けたほうが良いかと思います。

印象に残っていたのは、名前の長さをどうするかといったところです。あまり意識してなかったのですが、スコープの大きさによって名前の長さを変えると良い、と紹介されており、なるほどと納得させられました。
スコープの大きさと名前の長さを比例させることである程度のそのメソッドの役目が見えてきます。これは早速実践ですね。

日本語や英語もそうですが、曖昧な意味の単語というは少なからず存在します。filterやclipといった単語が紹介されておりましたが、filterだと選択したいのか除外したいのか確かに誤解を招きます。
（コードレビュー時などに、コーダーがどういう処理をしたかったかによって不具合なのか正しいのかの判定が比較的早く出せます）
このあたりはきちんとしたルール付けすることが大事かなと思いました。私場合だと駆け出しの頃は前述のgetとsearch以外に、registとinsertといった単語を意味もなく使い分けたりしてました。
（ちなみにregistという単語は存在せず、よくある間違いではあるのですが）
使い分けてたというか、どう名付けたか忘れている感じですね。名付けは慎重に行う。これは今後も強く意識していこうと思います。

とは言うものの、ゼロベースから構築実装するより既存環境の改修課題のほうが機会としては多いため、いきなり自分のルールを作って構築すると一貫性がなくなり逆に可読性が下がってしまいます。
あくまで一貫性を意識した上で既存のコードの延長線上で意識するということをやっていく必要があります。

コメントすべきことを知る ／ コメントは正確で簡潔に

意外と忘れがちなのがコメントですね。特に私はコメントが少ない傾向にあるので、今回かなり反省しました。
コメントの書き方について丁寧に記載した技術書は多くはないので敢えて記述方法を具体的に指示されることで多くの納得感が得られました。

この章を要約すると

１．コメントするべきでないことを知る。
２．コードを書いているときの自分の考えを記録する。
３．読み手の立場になって何が必要になるかと考える。
４．入出力の実例などを踏まえて動作はできるだけ正確に説明する。

といったところになるかと思います。

コメントしましょうと言うと肩に力が入ってしまい、何でもかんでもコメントしてしまいがちになります。例えば

class Account {
   public:
   // コンストラクタ
   Account();

これは本に記載されている極端なコード例なのですが、見れば一発でわかるようなコードにコメントはいらないということですね。書きすぎても行数が増え確認作業が増えて可読性が落ちます。
また、変数名や関数名を説明するためのコメントなども説明する必要があるのであれば命名を再検討すべきだと訴えています。
これは例としてクラスのスタート部分だけなので、まぁそうだよねってレベルで終わってますが、多分大量にこんなコメントが記載されていたらコード自体がわからなくなり発狂してしてしまいそうな気がします笑

個人的にはコードを書いているときの自分の考えを記録するというのが意外と難しいかなと考えています。読み手の立場になって考えるのも然りです。コードを書いているときはすごく理解が深いので、ある程度これはわかるだろうと無意識的に端折ってしまう可能性があるためです。
でも実際１年後に自分が書いたコードを見てみると、結局１つ１つコードを追いかけてこの関数なんだっけ？となってしまう。

ではどうすべきか。
本では、質問されそうなことを想像しながらコメントを記述するのが良いとありました。
「このコードを見てビックリすることは何だろう？どんなふうに間違えて使う可能性があるだろう？」
と自分に問いかけます。

なるほど。まぁ言われてみたらそうなんですが、このあたりを意識してコメントを書いたことはなかったなと思い、早速明日から使えるテクニックだなと思いました。

コードに思いを込める

文中にアルバード・アインシュタインの言葉で「おばあちゃんがわかるように説明できなければ、本当に理解したとは言えない。」が紹介されていました。
これは本当にそのとおりで、物事を理解したつもりでもいざ人に説明しようとしたらしどろもどろになってしまい、きちんと相手から理解を得ることができなかったといったことが往々にしてあります。
逆に、説明することにより理解が深まります。
この話はコーディングでも言えることで自分が思い描いているイメージを簡単な言葉で説明できるかどうかというのは非常に重要になってきます。

文中ではラバーダッキング法が紹介されており、リモートワークがメインの今の御時世ではなかなか人を捕まえて話を聞いて！なんてできないのでかなり有効な手段かなと思いました。

ラバーダッキング法とは

声を出せる環境にないという方はエクセルでもメモ帳でも今考えていることをとりあえず全部文字として書き出してみるとよいでしょう。

まとめ

今回すごく当たり前だけど意識的にできていないことをピックアップしてみましたが、他にも多数の内容がありますので興味を持たれた方は読んでみてください。

すごく読みやすい本で、初心者の方でもスラスラと読める本かなと思います。
私の場合、掲載されている大半は「あ〜そういうこともあったね。」といった過去に指摘された or 失敗したことや、ソース解読などをしている際にこの書き方勉強になるねと思った内容（過去の経験）でした。
実務を何年もされている方でしたらそこまで目新しさのある内容ではないかなといった印象です。

しかし、良いコードとは何かというのを原点に立ち返って思い出させてくれる良本だと思います。
最近は特に読みやすいコードを書くぞ！ということを意識的に強く思うことがなかったので（全く無かったわけではないが）、まずは半年後の自分に向けて意識的にコーディングするようにしてみようと思います。

さいごに

ソリューションウェアでは、さまざまな分野の案件を幅広く持ち合わせておりスキルアップには最適の環境です。自身のスキル向上に悩んでいる方、エンジニアとしてもう一皮むけたいと考えている方、一緒に私達と働きませんか？お気軽に一度ソリューションウェアにご相談ください。

参考

リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック / DustinBoswell / TrevorFoucher / 角征典