完璧なコーディング規約を定めて、メンバー全員がその規約に忠実に従っていれば、プロジェクトのコードは無駄の無い美しいものになるでしょうか？
必ずしもそうとは言えません。むしろ、厳しすぎるコーディング規約は逆効果になってしまう場合もあります。
そもそも、コーディング規約は美しいコードを書くためのものではありません。
プロジェクトのメンバーというのは通常、経験年数も育ってきた環境も最初に覚えた言語もバラバラです。
そのような集団がそれぞれ自分の書きやすい書き方でコーディングを進めたら、同じプロジェクト内、下手をすると同じファイル内でも全然違う書き方が混在してしまいます。
コーディング規約というのは、メンバー間のコードの差異をできるだけ無くし、プロジェクト全体の統一感を出すために必要不可欠なものです。
キャメル記法を使う、メソッド名は動詞から始める、インデントは半角スペース4文字、etc…
では、コーディング規約を細かく定めることによって、リファクタリングが不要なレベルの綺麗なコードが出てくるかというと、答はノーだと思います。
もちろん、統一感が出ることで一定の美しさは得られますが、それ以上にはなりません。
その点を混同しているリーダーやマネージャーが少なからずいるように思われます。
例えば、「ネストは○段階まで」「１つのメソッドは○○行まで」「メソッドの引数は○個まで」という風に細かく定めたとします。
そうすると、人というのは無意識に「○段階までならOK」と解釈してしまい、それ以上に減らす努力をしなくなってしまいます。
また、レビューで「ここ、こうすれば行数減って読みやすくなるよ」と指摘しても、「でもコーディング規約には違反してないじゃないですか」と返されると何も反論できなくなってしまいます。
そもそも、一番綺麗な書き方というのはケースバイケースであり、一概に決められるものではありません。
例えば、300項目のCSVファイルを出力するとします。
この場合、「メソッドは20行まで」という規約に縛られて20項目ずつ出力メソッドを分割するより、適切なコメントを挟みつつ300項目を1つのメソッドで出力するほうが読みやすいはずです。
300項目が1つにまとまっている方が、仕様変更による項目の増減や順番の変更も容易になります。
もう一つ例を挙げると、ループ内でDBにアクセスしたりAPIを呼んだりするケースです。
パフォーマンスの悪化につながるため、安易にやるべきではない処理なのは間違い無いですが、だからといって杓子定規に禁止すべきではないと思います。
実際、「1回の処理はどんなに遅くても0.1秒、ループは最大5回までだから、十分許容できる。むしろ、無理して処理を1回にまとめた方がパフォーマンスが悪化する」という例を見たことがあります。
言わなくてもこのような判断をしてくれるメンバーがプロジェクトにそろっているのなら、統一感を出すための最低限のコーディング規約を定めつつ、後はプロとしての各個人の裁量に任せるべきだと私は考えます。
逆に、メンバー全体の経験が浅い、明らかにスキルの低いメンバーがいる、外注会社に発注する、等の場合は美しさよりもまずは統一感の方が重要なはずなので、コーディング規約をどこまで細かく定めるかもまたケースバイケースだと思います。