「リーダブルコード」を改めて読んでみて(その2)

前回の記事の続きです。前回の記事では1章の内容に触れ、書籍のタイトルにもなっている"リーダブル"なコードとはどういうものかについて書きました。

今回の記事では第Ⅰ部(2-6章)の内容に触れていきます。第Ⅰ部は「表面上の改善」というテーマで、以下の3点にフォーカスしていました。


"いい"名前の付け方

2-3章では、変数や関数などに対してどのような名前を付けるべきかについて言及しています。重要だと感じたのは以下のフレーズです。

  • 名前は短いコメントだと思えばいい。
  • いい名前というのは、変数の目的や値を表すものだ。
  • 最善の名前とは、誤解されない名前である。つまり、君のコードを読んでいる人が、君の意図を正しく理解できているということだ。


このあたりから、"いい"名前とは他の人が見たときに複数の解釈をされることがなく、かつ処理の実態に則した名前のことで、そのような命名を行うために試行錯誤する(安易にretvalgetXxx()などとせず)ことが重要だと解釈しました。

命名に関してはQiitaの命名規則タグの記事類語辞典(Thesaurus.comなど)を活用してボキャブラリを増やし、自分なりの命名規則をコーディング規約の一部としてまとめたいと思います。

"美しい"コードの書き方

4章では、美しいコードの書き方について言及しています。ここでいう"美しい"とはプログラムの設計やリファクタリングなどのことではなく、単に読みやすいという意味で使われていました。
内容的にはいわゆるデザイン原則の話で、以下のような観点でコードを整理することで可読性を上げていこうといったことが書かれていました。

  • 関連する変数や関数、処理の塊を作る(近接)
  • タブやスペースを使って変数や処理、コメントの位置を揃える(整列)
  • 類似の処理のフォーマットを統一する(反復)


デザイン原則については、以下のサイトをはじめ多くの参考資料があるので、参考にしてみてください。
webdesign-trends.net


"価値のある"コメント

5-6章では、価値のあるコメントについて言及しています。重要だと感じたのは以下のフレーズです。

  • コメントの目的は、書き手の意図を読み手に知らせることである。
  • コードからすぐにわかることをコメントに書かない。
  • 欠陥を文書化するのを恥ずかしがってはいけない。
  • 定数を定義するときには、その定数が何をするのか、なぜその値を持っているのかという「背景」が存在することが多い。
  • ファイルやクラスには「全体像」のコメントを書く。


このあたりから、"価値のある"コメントとはコードを書いた人しか背景が分からない部分や、他の人がコードを読んだり使ったりする際に困るであろう部分に対する補足情報だと解釈しました。

「資料は一人歩きする」とよく言ったりしますが、コードもまさにその資料にあたり、他の人が読んだときに書いた人が口頭説明する必要がない状態になっているのが理想形なんだなと感じました。
今までコメントを単なるメモのように使っていたり、ルールとしてKDocをなんとなく書いていたりすることが多かったので、今後はコメントする内容を吟味していきたいと思います。


次回の記事では第Ⅱ部(7-9章)の内容に触れていきます。第Ⅱ部は「ループとロジックの単純化」というテーマです。
より具体的なコードの書き方の話へと進んでいきます。


一連の記事はこちらです。
tkhs0604.hatenablog.com tkhs0604.hatenablog.com tkhs0604.hatenablog.com tkhs0604.hatenablog.com tkhs0604.hatenablog.com tkhs0604.hatenablog.com