プログラミング業界では定期的に「美しいコード」が話題になり、そのたびに炎上が発生します:
- コードの美しさは実務には関係ない
- 美しくても動かなければ意味がない
- 「美しさ」は主観的で、プログラマーの自己満足に過ぎない
- 汚くたって俺は読める。読めないお前が悪い
などなど・・・
私もコードは美しくあれかしとは思いつつも、
- 「確かに『美しい』って曖昧だよな」とか、
- 「どうして
=の位置がそろっているのを『美しい』というのだろう？『整然としている』なら分かるけど」とか、 - 「『可読性が高い』でもいいけど、今一つ『美しい』との違いが判らん」
- 「そもそも、どうして美しいコードの方が読みやすいと言えるんだ？」
と、割り切れなく思っていました。
ところで、最近の心理学・脳科学ではこんな説があるようです（本当かどうかは知らないよ）：
中野：（中略）美人の顔って対称性が高いって言われますよね。あれは別に体が健康だからではなくて。体の健康さとは相関がないということがわかったんです。
佐渡島：あ、そうなんですか。
中野：実は、認知しやすいから。
佐渡島：顔の認知が。
中野：顔の対称性が高かったら、半分のリソースで済みますよね？
佐渡島：右目と左目で違う脳を使ってますもんね。
中野：そうですね。すごく楽に認知できるわけです。平均顔に近い人も平均顔だから、それも認知負荷が低い。認知負荷が低い顔ほど、好ましく思う。
佐渡島：へぇ。健康な体を見分けてるわけじゃないんですね。
中野：うん、違うみたいですね。「今までそういうふうに言われてたけど、どうも違うようだ」という説が出てきてます。
これを見てピンと来ました。
モヤモヤしがちな「美しいコード」は、「認知負荷が小さいコード」 と言いかえられるのではないでしょうか？
例えば・・・
例：「= や ) の位置を揃えよう」
△位置が揃っていると美しいから。
〇位置が揃っていると、位置を毎回確認する必要が無く、認知負荷が小さいから。
例：「クラスや関数に一貫性のある命名をしよう」
△名前が一貫していると美しいから。
〇名前が一貫していると、一見するだけでクラスや関数の役割や動作が把握でき、認知負荷が小さいから。
「認知負荷が小さいコード」の良いところは、「美しいコード」よりも応用が広く利きそうなことです。
例：「関数を切り出すときは意味のある名前を付けられる範囲を選ぼう」
〇人間の脳は、意味のある名前のついたものを理解しやすい特性があり、「ステップ２」「～のあとに必要な処理全部」のような抽象的な名前より、意味のある名前の方が認知負荷が小さいから。
例：「関数名やテストの見出しには、単語の羅列ではなく、英文法的に正しい名づけをしよう」
〇人間の脳は、単語の羅列よりも文法的な文を効率的に処理できるようになっており、正しい文の方が認知負荷が小さいから。
「美しいコード = 認知負荷が小さいコード」はあくまで私の思いつきですが、先輩の言う「美しいコード」に納得できなかったり、後輩が頑なに「美しいコード」を拒んだりしたときは、「認知負荷が小さいコード」を思い出してみてください。