ソースコードが汚くなる？ワケとその対策
プログラム書くお仕事してると、ソースレビュー、つまり、他の人にソースコード（プログラムの原文）を見せたり共有することがある。
特に海外の人とソースコードをやり取りすると、「なんじゃこりゃ？」と思うような、読めない＆読みづらいソースコードが出てきたりする（逆もあり）
私自身も、昔は「おまえのソースコードは汚い」とか、「可読性が大事だ！」とか、よく批判を受けた。今でも綺麗ではないと思う笑
そこで気になったのが、同じソースコードを「綺麗だ！」「汚い！」と評価する人が、人によって全然異なる、ということである。
今回は、そのソースコードの綺麗さ、可読性についてお伝えする。
ソースコードをレビューしていると・・・
海外のエンジニアと仕事すると、「Very clear！（≒わかりやすい）」とか、「It’s difficult！（≒難しい、ややこしい！）」等、同じソースコードでも人によって意見が分かれる。
よくよく考えたら、自分の部屋に友達や知人、彼氏彼女を招いた時も同じことを言われたことはないだろうか？
人によっては「整理整頓できてるね」といわれることもあるだろうし、
「おまえの部屋きったねーな」といわれることもある。
ソースコードが汚くなるワケ
そもそも部屋とかソースコードって、なんで汚くなるのか？を考えて見たら、部屋の綺麗・汚いといった観点に近いのではないだろうか？
たいていの人が「部屋が汚い！」って思う場合、
- 掃除しない
- どこに何を置くのか、ルールやポリシーがないので、
乱雑にモノが置かれている。 - モノが多すぎる
といった理由が多い。ソースコードも同様である。
- リファクタしない
ソースコードが肥大化する。共通処理がいろんなところに散らばる。 - コーディングルールがない。暗黙知（≒言わなくてもわかるだろ）でソースコードの書き方が決まっている。
- ソースコードが長い！
ソースコードが汚いと評価される背景として、以下の理由があげられる。
問題なのは、その「汚い」という基準が、人によって全然異なることである。
汚いといっても、いろんな事情があるんだよ
話が飛ぶが、マレーシアの公衆トイレは、すごく汚いことで有名だ。
シンガポール等と比べると雲泥の差である笑
ところが、われわれ日本人だと立ち入ることすらためらうのに、マレー人は普通に使っている。
ということは、ソースコードの汚さも便所の汚さも、その相違点って実は同じじゃないのか？と思うようになった。
つまり、「なんで汚いのか？」「なんで汚くても使えるのか」を深堀していかないと、批判しようがないな、ということだ。
マレーシアの便所の場合は、清潔感の感性の違いから生まれるのだが、ソースコードも同じだったり、納期が短すぎてきれいにできなかったりと、様々な事情がある。まず、その違いをはっきりと言語化して、前提条件を明確にしたうえでディスカッションしたほうが良いな、と最近思うようになった。
一番無価値なのは、ソースコードが汚い＝悪という善悪論で終わってしまい、人格攻撃で終わってしまうことである。
それでは、プログラマーが育たない。
汚いソースコードはダメ！の前に、なぜきれいにする必要があるのか？を明確にする
昔どっかで「ソースコードを憎んで人を憎まず」という話を聞いたことがあるが、個人的な経験として、最後には「坊主憎けりゃ袈裟まで憎い」になる。
それはなぜか？
１つに「汚さ」が人間の善悪論をベースに考えられてるからである。
最たる例は、公共交通機関内で飲食し、車内を汚す人だ。
「公共交通機関なんだから電車の中を汚くするのはダメだ！当たり前だろ！」って思った方は要注意である。
貴方は心の中で思っていても、他の人がそうとは限らない？
日本人は、価値観が近い人が集まっているので、「相手も同じ考えを持っているはずだ」という前提条件を、盲目的に信じ込んでしまう。
なので、自分にとって当たり前のことや理想を相手に押し付けるのはナンセンスだ。
むしろ、「なぜ綺麗にする必要があるか」「どこまで綺麗にするべきか？」を、もっと明確に言語化したほうが良い。
例えば、wordpressのテーマ開発の場合、やみくもにfunction.phpに処理を追加してしまうと、後で見直すとどこに書いてあるかわからないので、修正に時間がかかったりことがある。
そこで、
「function.phpは、管理画面の処理とフロントの処理を別のファイルに外だしして綺麗にしよう。なぜなら、一番カスタマイズされてソースコードが膨らみやすく、あとで修正するときに探すのが大変だから。」
みたいな感じで、コーディングルールを決めるだけでなく、その背景までしっかりと言語化するようにしている。
そうすることで、あとから別の人がソースコードをいじったとしても、 コーディングルールが目指す背景や目的もわかりやすいので、汚くなりにくくなる。
ソースコードが汚い場合の不利益を説く
現場の目線からすると、ソースコードってある程度はきれいじゃないと、メンテナンスや拡張性に困ることが多い。
そこで、ソースコードが汚いことによる不利益を、コーディングルールの展開時に合わせて伝えておくと、後からカスタマイズする人には理解しやすいし、ルールを守ってもらいやすくなる。特にセキュリティに関する場合はなおさらだ。
特に、ＮＧを定義する場合は、なぜＮＧなのか？も含めて言語化しておくと、別の人がソースコードをいじっても、それほど大きなセキュリティの脆弱性は生まれにくいのかもしれない。ただし、ヒューマンエラーは必ず発生するので、セキュリティチェックはある程度自動化する必要があるが・・・。
おまけ：まずは「コードの汚さ」の定義からはじめよう！
高橋文樹.comの以下の記事が、かなり良い記事だったので参考にさせていただいた。ソースコードが汚いと言われてへこんでいる人は、是非一度読んでみることをお勧めする。