プログラミングにおける可読性は何故大事なのか

良いコードを書くための”習慣”
上記を書いた人です。

最近、品質管理に関する業務を対応しているので日々思うことがあります。
“可読性”とは＿＿

この記事ではプログラミングをする上での”可読性”とは？を深掘りしていきます。
こんな人向け
・”可読性”の意味を知りたい人
・なんとなくな可読性でプログラミングをしている人

まずはwikipediaで確認してみましょう。

可読性 – Wikipedia

読み取れる性質、読み取れる度合などを表す言葉
プログラミングにおける可読性（readability）とは、プログラムのソースコードを人間が読んだときの、その目的や処理の流れの理解しやすさを指している

特に定義に関して疑問は起きませんでしたが、以下文言はとても重要だと思うので抜粋します。

よく使われるイディオムによる簡潔なコードを「可読性の低いコード」と見なしてしまうことがあり、読む人間のスキルもまた重要である

つまり、「可読性を向上する」と「新人プログラマでも読めるようにする」はイコールではないを表します。

勉強するために公開されているコードを読んだり、プロジェクトにてレビューをしたとき以下のようなことを思ったことがあるはずです。
・この変数にはどういう値が入ってくるのか
・この関数はどういう時に実行されるのか
etc…
それらを理解するのに時間がかからないコードが”可読性が高い”に繋がると思います。

# NG例
x = 0.1
y = 0.08
＃　OK例
sales_tax = 0.1
reduced_tax rate = 0.08


可読性は大事と言いますが、それだけでは自分で考えて実行することはできません！
何故、可読性は大事にする必要があるのでしょうか。

まずは開発工程をざっくりあげてみました。
・仕様理解/調査
・設計
・機能を改修/追加/流用
・レビュー
・テスト

このリストを見て気づいた方もいるかもしれませんが、ほとんどの工程で”コードを読む”必要があります。
つまり可読性が低いと読む労力が必要になり、そのほとんどの工程の生産性を下げることになります。
関係者のためにも…、未来の自分のためにも可読性の高さは重要になるわけです。

「可読性とは」「可読性が高いことが何故大事なのか」は理解できました。
では実際にどうすれば可読性を高められるのでしょうか？

様々な手法が有識者によってまとめられていますが、結論脳のリソースが取られる”読むのが嫌になるコード”を避けることで、可読性を下げることを防ぐ意識が大事なのではと感じました。
言っていること変わらない気が…と思うかもしれませんが、可読性をあげようあげよう！となると手法が目的になりがちです。

例を条件式であげてみます。

if type && (!data1 || data2 || (data3 && data4))
~処理~

どの値が入ってくるのかわからない変数名が悪いことは大前提です。
それを除いたらパッと見1行で収まったシンプルなif文に見えるかもしれませんが、()が入り組んでいると値を理解しても、さらにその先の条件を理解するのが大変です。
つまり短ければ良いというものではなく、理解に時間がかかりそうな式は分割するべきと考えます。

hoge_valid = data3 && data4
hoge_type = !data1 || data2 || hoge_valid
if type && hoge_type
~処理~


このように「巨大な式は分割するべき」という手法が目的となってしまってプログラミングすると
どこからが巨大？どこから分割するべき？という思考が入ってしまうことでしょう。
この式の意味を理解しにくい・読みにくいから分割するか…という意識の方が、より意識的に可読性を高められるのではないでしょうか。

他に例をあげるとアーリーリターン（早期リターン）もそうです。
アーリーリターンはやっておけばOK！と何も考えずに対応すると、処理が多岐にわたる可能性のある関数やメソッドでは改修がしにくくなる（アーリーリターンの処理が肥大化など）ので、逆に可読性が下がる可能性があります。
つまり、アーリーリターンが正義！でも悪！でもなく、何故アーリーリターンをするのか目的を理解して対応するべきだと感じました。

これは、あくまで持論です。
好き嫌いがあったり読み手に依存したりするので、コードレビューといった場で他開発者と議論していきたいですね。

可読性とはそもそも何なのか、工程においてどれほど重要なのかを理解することができました。
現在・未来の誰かのために、常に「このコードは理解しやすいのか？」という視点で自問自答を繰り返して、読むのが嫌なコードにならないように意識しましょう！
また、自分で開発を進めていくと慣れのせいで、自問自答しても改善しにくくなる状況に陥る場合もあるので
定期的に他人のコードに触れて、わかりやすい/わかりにくいの感覚を維持していくことも大事ですね。

書籍：リーダブルコード