コードの「可読性」って何？読みやすいとは何か・読みやすいことのメリットとは
新人プログラマがコードレビューしてもらった時に、「可読性」に関する指摘がすんなりと理解できてすぐ改善していける人と、いつまでも理解できず改善しない人がいる。というか、年々理解できない若手が増えていく気がしている。
今回は、可読性・読みやすさとはどういうことか、「読みやすい」と云われる状態にすると何が良いのか、というところを振り返り、読みやすいコードを書くための心構えや考え方をまとめたい。
「読みやすさ」の種類
コードの可読性にはいくつかの種類がある。
- コーディングスタイルが揃っていること
- インデントやスペースの入れ方がある一定の規則に沿っていること。
- システム化とは物事を規則化していくことだから、システムエンジニアは規則を作って従えないといけない。できれば規則は可視化したいものではあるが、見えない規則も意識できないといけない。
- コーディングスタイルが周りの既存コードと揃っていること
- これは、そのチーム・そのシステムにおいて、周りの既存コードと同じようなスタイルで書かれている、ということだ。
- その人が書くコードとしての統一感はあっても、周りの既存コードから浮いていると、全体を通した時に読みづらい。
- 処理が簡潔に書かれていること
- 不必要な初期化処理が混じっているとか、条件分岐とループが混在したりして、「結局何がしたい処理なの？」が読み取りづらいと、コードを理解するのに時間がかかる。
- 俗にいう「ネストの深さ」もこの部類。ネストごとの処理内容を全部暗記しておかないと読めないというのは、頭を使う。頭を使わないと読めないコードは、すなわち読みづらいコードだ。
- 手続き型で書かれたコードも、「前後の流れを完璧に覚えておかないと読み間違いが発生しうる」という点で、頭を使う。
- 適切なメソッド名・変数名が書かれていること
- 過去に何度か書いてきたが、名前によってそのメソッドや変数の役割や責任範囲を示すことで、「コイツはこういうことをしてくれる処理なんだろうな」と推測できるようにする。
- そうすると、具体的なコードの中身を全て読んで暗記しなくとも、大体推測して読めるようになる。
つまり、「インデントさえ揃えれば良い」ワケでもないし、「命名だけちゃんとしていればインデントがメチャクチャでも良い」ワケでもない。
こうして見てみると、「インデントが揃っている」とか「周りと馴染んでいる」とかいう目線は、具体的な「行」を読んでいるのではなく、モニタに映されたコード全体のカタチというか、雰囲気を見ている感覚に近い。実際にコードを読む時も、モニタから目を離して全体を読んだ時に、どう感じているか、に近いのではないだろうか。
一方、変数名や処理の流れなどは、具体的な行や、数行の「段落」レベルの細かな話。コチラは逆にモニタに目を近付けて、一行一行をちゃんと読んでいった時の感覚。
モニタとの距離 (= 一度に視界に入れるコード量) に応じて、「読みやすさ」を判断する基準が少し違う、ということだ。
実装時に自分が読みやすいコードを書けているか確認する時に、意識的にモニタとの距離を変えてみよう。実装中はついモニタに顔が近付いているが、目線を離して遠ざけた時に違和感がないか。俗にいう「コードスメル」「臭いコード」も、こうやってモニタから距離を離すと見付けやすかったりする。コード全体のスタイルや可読性が悪いということは、細かな実装もまともである可能性が低いからだ。
なぜ「読みやすさ」が大事なのか
ところで、そもそも何故「コードの読みやすさ」が大事なのだろうか。
- 自分で書いたコードは自分でちゃんと読めるし、問題ない。
- 実装してリリースされたら「コードを読む」機会なんてそうないんだし、さほど重要でもないでしょ。
そう思うかもしれない。だがコレは、実装者としての視野でしか物事を見ていないからこその意見だ。
- まず、コードレビューは実装した本人ではなく、別の人が行う。別の人がそのコードが実現する処理の正しさを確認するために、理解に時間がかかったり、誤解を招くようなコードだと、レビュアーの時間を奪うことになる。つまり会社としてはレビュアーの人件費が余計にかさむことになる。
- リリース後、何かバグがあった時に、原因箇所が特定できないような読みづらいコードだと、チームメンバ全員が原因特定に時間を奪われる。
- 人間にとって読みやすく書かれたコードは、プログラムの構造も平易になっていくので、システム的にも解析がしやすく、バグの特定が容易になる。
- 一度実装した箇所に機能を追加・変更する機会は、結構ある。そういう時は既存仕様を確認するためにコードを再度読む機会も増えるし、実装時は既存処理を壊さないように追加実装する必要が出て来る。読みづらいコードは要するに何をしているのか分かりづらいコードなので、改修時にバグを埋め込んでしまう恐れが高まる。
- そのコードを書いた当時はよく覚えていても、数ヶ月後に自分のコードが正しく理解し直せるとは限らない。こんがらがった読みづらいコードを書いた時の自分と、次にそのコードを読んだ時の自分は別人だ。自分が自分の成果物をいつまでも記憶していられると思うな。
- 自分がその現場を離れたら、次は別の人がそのコードを保守することになる。自分の手を離れたコードで他人に迷惑をかけることになる。後任者がコードを理解しきれなかったせいでバグが発生したりしたら、それは会社組織としては損失。原因を作った人間のことは皆忘れない。
実装者の目線だけで物事を考えると、「今実装しているこの瞬間」のことしか意識がないので、「読む」意識がそもそもなく、「書く」ことだけに集中している。
しかし、コードというものは書く時間より読まれる時間の方が圧倒的に長いのだ。しかも、レビュアー、他のメンバ、後任者、「未来の自分」など、読み手はいずれも他人だ。他人に分かってもらえないといけないのに、読みやすさを考えなくて良いはずがない。
そして、読みづらくて読めなかったことによる損失のリスクが極めて高い。一度稼働したシステムで不具合が出たり、改修時にデグレードを起こしたりするのは、システム屋の評価としてはとても厳しいものになる。コードの読みやすさを意識しなかったことが、回り回って会社の評価・売上を落とすことに繋がりかねない。
これは大袈裟な話ではなく、「何でこんなに改修に時間がかかるの」とか「何でこんな初歩的なバグで本番障害が起こるの」とかいう問題は、仕様書でも PM でもなく、全てコードが引き起こしている問題なのだ。だから、コードを生み出す時はそのコードが今後どう扱われていくか、考える必要があるのである。
何が世間一般的に「読みやすい」とされているか・どうしたらそう書けるか
コードの読みやすさとは、「書いた自分自身が読みやすいこと」というよりは、「自分以外の人が読みやすいこと」が重視されることが分かった。
では、世間一般のプログラマにとって、どんなコードが読みやすいのか。どうすると読みやすくなるのか、を知ろう。コレは自分の中で考えて探すのではなく、定石を知ることが大事だ。自分目線なんて要らないので、「自分で考える」なんて不要。世間の物事をたくさん知れ。
- 参考：リーダブルコード : 鍵となる考えのおぼえがき - Qiita
- 基本的には「リーダブルコード」という書籍を基礎的な経典として頭に叩き入れておくと良いだろう。エンジニア名乗るなら必ず読め。
- 参考：どうしようもないエンジニアから卒業するために考えるべきたった1つのこと - Qiita
-
いかにコードを読む側の考える時間を短くするか
-
- 参考：変数や関数の名前がいつの間にか分かりにくくなる問題 - Qiita
- 改修していくと読みづらいコードになる例。
-
変数を追加するとき、他の変数の名前を再検討せよ
- 参考：新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 - Qiita
- 基本情報処理試験でも出てくる「ド・モルガンの法則」を使って、論理演算子を整理する。
- 処理はメソッドに切り出すと可読性が高まる。処理の流れが手続き的ではなくなるため、「上から下に読む」ことができなくなるので素人的には読みづらく感じるが、コードを読む時にイチイチ覚えておかないといけないことを減らすことが大事で、そのためにはメソッド切り出しは基本中の基本。
- 説明的な変数を作る。名前で説明する。
- 変数への再代入を減らすことで、その変数の役割やスコープを小さく保つ。
- ネストを減らすための「ガード節」という考え方。
- 参考：CleanCode読書メモ - Qiita
-
別の人がコードを読んだ時に、「
aはaccountのことだな」のような脳内変換（メンタルマッピング）が必要になる名前を付けてはいけない。 // 事前処理 ////////////////////みたいなバナーコメントは読みやすくならないので止める。こうしないと分かりづらいということは、つまり処理を区切りれていない・区切りたいことの現れなのだから、メソッド切り出しするべき。
-
- 参考：よくあるコーディングスタイル改善パターン - Qiita
ifに関する読みやすさ改善パターン。
- 参考：【Java】どうにもコーディングし直したくなってしまう書き方まとめ - Qiita
- Java に限らずいえること。
- 参考：ネストの深さは闇の深さ - Qiita
- ネストが深いと「脳内メモリが足りなくなる」。コレが「読みづらさ」の要因であり、バグの温床。
「命名規則」もそうだが、「読みやすさ」に関しても、「コレだけ学べば終わり」というモノではない。常に学び続け、その場において適切な改善パターンを見極められるようにしないといけない。
読みやすさの判断基準を「自分」に持たないこと。書いている自分は読むことはないので、他人にとっての読みやすさを考える。それはつまり、他人の立場、他人が持つ知識を考えること (他人は書いている自分と同じだけの知識は持ち合わせていないのだから)。
