わかりやすいコードとは

分かりやすいコードとは、自分はもちろん、他の人が最短時間で理解できるようなコードのことを指しています。開発する時にコードが読みやすければ拡張しやすく、複数人で開発するのも容易であり、より速く開発できます。開発にあたるエンジニアが多いほどコミュニケーションのコストは増えますが、読みやすいコードはコミュニケーションのコストを下げ、トラブルを減らし、バグをすぐに見つけやすくなり、効率的な開発ができます。

今回紹介する本は『リーダブルコード 』

リーダブルコードはは特定のプログラミング言語でのコーディングを学ぶ本ではありません。特定のプログラミング言語にとらわれず、プログラムを書く際に意識しておきたいポイントや、コードをどのように書くと良いかを提唱する本になります。いくつもの方法がある中で、より良い方法を考えて選択していきます。プログラミングを始めたばかりの入門者の方は、何が良い方法なのかその判断がなかなかできないと思います。

今回はこの本の第I部（表面上の改善）の要点を取り上げました。

なぜこの本に興味を持ったか？

今年の7月から本格的な開発に携わるようになって、毎日コードを書いたり、読んだりしてます。つい最近に、１、２ヶ月前にに自分が書いたコードを理解するのに時間かかってしまうことがありました。他の人がそれを読んだらもっと時間かかるだろうなと気つきました。そこを治したくて、わかりやすいコードの書き方を調べたら、この本に目をつけました。

 

汎用的すぎる名前は避けましょう

変数や関数、クラスすべてにおいて名前をつける時は、その名前に情報を詰め込みましょう。大切なことは、変数などをパッと見てその名前が何を表しているのかがわかるような命名をすることです。

インターネットからページを取ってくる関数の場合の例

よりも

の方が明確。

「get」という単語だと、意味が広くて、このページはどこから取ってくるのかわからない。ローカルキャッシュ？データベース？インターネット？など様々受け取れます。
なので、インターネットから取得する場合は「download」の方が明確です。

こういう風にメソッドの情報をイメージしやすい名前にすると、コードが読みやすくなります。

 

もっとカラフルな単語を探す

英語は豊かな言語なので、選べる単語はたくさんあります。いくつかの単語と状況に合わせて使えるもっとカラフルな単語を紹介します。

単語	代替案
send	deliver,dispatch,announce,distribute,route
find	search,etract,locate,recover
start	launch,create,begin,open
make	create,set up,build,generate,compose,add,new

 

誤解されない名前

わかりづらい名前は控えましょう。以下が本書に書かれた簡単な例です。
範囲を指定する場合はfirstとlastを使用する。

だと4は範囲に含まれるかわからない…

にすると4が含まれることがわかります。

他の例：

• 限界値を明確にするには、名前の前にmax_やmin_をつける
• 包含/排他的範囲にはbeginとendを使う
• ブール値の変数は、頭にis,has,can,shouldをつけることが多い

 

プログラムでコメントするべきこと

コメントの目的は書き手の意図を読み手に知らせることです。コードを書いている時は書く人にはたくさんの大切な情報があるが、他の人がそのコードを読む時はその情報は書かれていない。コードを読む人が見るのは目の前にあるコードだけです。コメントを書く際に意識すべきことは以下3つ

• コメントするべきでは「ない」事を知る
• コードを書いているときの自分の考えを記録する
• 読む人の立場になって何が必要になるかを考える

プログラムでコメントするべきではないこと

コメントを書くとその分読む時間が長くなり、また画面を占めてしまうため、なるべくいらないコメントは書かないことです。ではコメントすべきこととすべきでないことの違いはなんでしょうか？コメントのコメントをしないことです。

例えば

これは価値がないコメントです。

シグネチャからsubtreeの中のnodeを見つける関数というのは容易にわかります。

もし仮に上記のようなケースでコメントを入れないとわからない場合は、名前が悪いケースになるので、名前を変えることをしましょう。

業務で活かせることができる点

開発に携わるから、自分はとにかく早くタスクを終わらせるように、コードの読みやすさを軽視してしまいました。その結果、自分で自分が書いたコードを理解するのに時間を掛かってしまいました。まだこの本の第I部しか読み終わってないですが、自分のコードを見返して、本当に汚いコードだなと気づき、コードの読みやすさの重要さを深く感じました。これからはチームで開発することも増えると思いますし、読みやすいコードを書けるように頑張っていきたいと思います。