はじめに

この記事は、システムエンジニア Advent Calendar 2016の14日目です。
いわゆるコーディング規約について、というかコーディング規約が、出来上がるコードにあたえる影響について、ここ数年考えていたことの一端です。
なお、具体的な規約の内容の話ではなく、抽象的な話が多めです。

たとえば

コーディングミスを原因とする障害があった場合に、再発防止としてコーディング規約に注意点を追記しておく、みたいな結論になることがあります。
まあ、Javaでよくあるやつで例えれば、
障害:+によるStringの連結をループ内でやっちゃったから超遅くなった
対策:ループ内でStringつないでく時はStringBuilder使え、って規約に追記しよう
みたいな感じですね。
気持ちはわからなくはないですし有効な対策となることもありますが、続けていくとコーディング規約がどんどん肥大化していくわけです。

もんだい

不思議なことに「こうやってコーディング規約を充実させていけば、誰でもよいプログラムが作れるようになるはずだ」と考える人もいます。(偉い人に多い)
果たしてそうでしょうか。
プログラマならわかってもらえると思いますが、コーディング規約があまりに肥大化するとそもそも読む気にならないし、気になったときにちょっと確認する、とかもやりづらくなります。
また、規約で縛るというのは「適切な実装がどれなのか判断しなくてよくする」ことでもあります。これは、レアケースを見抜いて「多数派ではないが適切な実装」をする、という選択肢を封じてしまいます。
これらはコードの質についてマイナスとなるでしょう。

こうさつ

チームで開発する場合、コーディング規約はあったほうが確実にいいと思います。特に、ネーミングやフォーマットに関しては必須と言えるでしょう。
ただ、禁止事項や推奨事項の類についてのコーディング規約を充実(肥大化)させていく、というのは、行く末がイマイチであるのは間違いなさそうです。
とはいえ、さまざまなシチュエーションに対応した規約を、「ほどほどのボリューム」でカバーできるとは到底思えません。

けつろん

誰でも「よいコード」を生み出せるようなコーディング規約、というのは現実的ではありません。
コーディング規約の役割は「よいコード」を生み出すことではなく、「最悪の結果を回避する」ということだと考えるのが良いと思います。
ざっと読み流せるくらいのボリュームで、残念なプログラマがやらかすのを回避しつつ、チョットデキルプログラマの邪魔をしない、そんなコーディング規約が理想でしょう。