Murga

個人的に言いたいコト・主張・気持ち。

コードの「可読性」って何?読みやすいとは何か・読みやすいことのメリットとは

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

Clean Code アジャイルソフトウェア達人の技

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

新人プログラマがコードレビューしてもらった時に、「可読性」に関する指摘がすんなりと理解できてすぐ改善していける人と、いつまでも理解できず改善しない人がいる。というか、年々理解できない若手が増えていく気がしている。

今回は、可読性・読みやすさとはどういうことか、「読みやすい」と云われる状態にすると何が良いのか、というところを振り返り、読みやすいコードを書くための心構えや考え方をまとめたい。

「読みやすさ」の種類

コードの可読性にはいくつかの種類がある。

  • コーディングスタイルが揃っていること
    • インデントやスペースの入れ方がある一定の規則に沿っていること。
    • システム化とは物事を規則化していくことだから、システムエンジニアは規則を作って従えないといけない。できれば規則は可視化したいものではあるが、見えない規則も意識できないといけない。
  • コーディングスタイルが周りの既存コードと揃っていること
    • これは、そのチーム・そのシステムにおいて、周りの既存コードと同じようなスタイルで書かれている、ということだ。
    • その人が書くコードとしての統一感はあっても、周りの既存コードから浮いていると、全体を通した時に読みづらい。
  • 処理が簡潔に書かれていること
    • 不必要な初期化処理が混じっているとか、条件分岐とループが混在したりして「結局何がしたい処理なの?」が読み取りづらいと、コードを理解するのに時間がかかる。
    • 俗にいう「ネストの深さ」もこの部類。ネストごとの処理内容を全部暗記しておかないと読めないというのは、頭を使う。頭を使わないと読めないコードは、すなわち読みづらいコードだ。
    • 手続き型で書かれたコードも、「前後の流れを完璧に覚えておかないと読み間違いが発生しうる」という点で、頭を使う。
  • 適切なメソッド名・変数名が書かれていること
    • 過去に何度か書いてきたが、名前によってそのメソッドや変数の役割や責任範囲を示すことで、「コイツはこういうことをしてくれる処理なんだろうな」と推測できるようにする。
    • そうすると、具体的なコードの中身を全て読んで暗記しなくとも、大体推測して読めるようになる。

つまり、「インデントさえ揃えれば良い」ワケでもないし、「命名だけちゃんとしていればインデントがメチャクチャでも良い」ワケでもない。

こうして見てみると、「インデントが揃っている」とか「周りと馴染んでいる」とかいう目線は、具体的な「行」を読んでいるのではなく、モニタに映されたコード全体のカタチというか、雰囲気を見ている感覚に近い。実際にコードを読む時も、モニタから目を離して全体を読んだ時に、どう感じているか、に近いのではないだろうか。

一方、変数名や処理の流れなどは、具体的な行や、数行の「段落」レベルの細かな話。コチラは逆にモニタに目を近付けて、一行一行をちゃんと読んでいった時の感覚。

モニタとの距離 (= 一度に視界に入れるコード量) に応じて、「読みやすさ」を判断する基準が少し違う、ということだ。

実装時に自分が読みやすいコードを書けているか確認する時に、意識的にモニタとの距離を変えてみよう。実装中はついモニタに顔が近付いているが、目線を離して遠ざけた時に違和感がないか。俗にいう「コードスメル」「臭いコード」も、こうやってモニタから距離を離すと見付けやすかったりする。コード全体のスタイルや可読性が悪いということは、細かな実装もまともである可能性が低いからだ。

なぜ「読みやすさ」が大事なのか

ところで、そもそも何故「コードの読みやすさ」が大事なのだろうか。

  • 自分で書いたコードは自分でちゃんと読めるし、問題ない。
  • 実装してリリースされたら「コードを読む」機会なんてそうないんだし、さほど重要でもないでしょ。

そう思うかもしれない。だがコレは、実装者としての視野でしか物事を見ていないからこその意見だ。

  • まず、コードレビューは実装した本人ではなく、別の人が行う。別の人がそのコードが実現する処理の正しさを確認するために、理解に時間がかかったり、誤解を招くようなコードだと、レビュアーの時間を奪うことになる。つまり会社としてはレビュアーの人件費が余計にかさむことになる。
  • リリース後、何かバグがあった時に、原因箇所が特定できないような読みづらいコードだと、チームメンバ全員が原因特定に時間を奪われる。
    • 人間にとって読みやすく書かれたコードは、プログラムの構造も平易になっていくので、システム的にも解析がしやすく、バグの特定が容易になる。
  • 一度実装した箇所に機能を追加・変更する機会は、結構ある。そういう時は既存仕様を確認するためにコードを再度読む機会も増えるし、実装時は既存処理を壊さないように追加実装する必要が出て来る。読みづらいコードは要するに何をしているのか分かりづらいコードなので、改修時にバグを埋め込んでしまう恐れが高まる。
  • そのコードを書いた当時はよく覚えていても、数ヶ月後に自分のコードが正しく理解し直せるとは限らない。こんがらがった読みづらいコードを書いた時の自分と、次にそのコードを読んだ時の自分は別人だ。自分が自分の成果物をいつまでも記憶していられると思うな。
  • 自分がその現場を離れたら、次は別の人がそのコードを保守することになる。自分の手を離れたコードで他人に迷惑をかけることになる。後任者がコードを理解しきれなかったせいでバグが発生したりしたら、それは会社組織としては損失。原因を作った人間のことは皆忘れない。

実装者の目線だけで物事を考えると、「今実装しているこの瞬間」のことしか意識がないので、「読む」意識がそもそもなく、「書く」ことだけに集中している。

しかし、コードというものは書く時間より読まれる時間の方が圧倒的に長いのだ。しかも、レビュアー、他のメンバ、後任者、「未来の自分」など、読み手はいずれも他人だ。他人に分かってもらえないといけないのに、読みやすさを考えなくて良いはずがない。

そして、読みづらくて読めなかったことによる損失のリスクが極めて高い。一度稼働したシステムで不具合が出たり、改修時にデグレードを起こしたりするのは、システム屋の評価としてはとても厳しいものになる。コードの読みやすさを意識しなかったことが、回り回って会社の評価・売上を落とすことに繋がりかねない。

これは大袈裟な話ではなく、「何でこんなに改修に時間がかかるの」とか「何でこんな初歩的なバグで本番障害が起こるの」とかいう問題は、仕様書でも PM でもなく、全てコードが引き起こしている問題なのだ。だから、コードを生み出す時はそのコードが今後どう扱われていくか、考える必要があるのである。

何が世間一般的に「読みやすい」とされているか・どうしたらそう書けるか

コードの読みやすさとは、「書いた自分自身が読みやすいこと」というよりは、「自分以外の人が読みやすいこと」が重視されることが分かった。

では、世間一般のプログラマにとって、どんなコードが読みやすいのか。どうすると読みやすくなるのか、を知ろう。コレは自分の中で考えて探すのではなく、定石を知ることが大事だ。自分目線なんて要らないので、「自分で考える」なんて不要。世間の物事をたくさん知れ。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

  • 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/06/23
  • メディア: 単行本(ソフトカバー)
  • 購入: 68人 クリック: 1,802回
  • この商品を含むブログ (138件) を見る

「命名規則」もそうだが、「読みやすさ」に関しても、「コレだけ学べば終わり」というモノではない。常に学び続け、その場において適切な改善パターンを見極められるようにしないといけない。

読みやすさの判断基準を「自分」に持たないこと。書いている自分は読むことはないので、他人にとっての読みやすさを考える。それはつまり、他人の立場、他人が持つ知識を考えること (他人は書いている自分と同じだけの知識は持ち合わせていないのだから)。