コーディング標準の均一性が高すぎる可能性はありますか？

均一性が大きすぎるということはありますか？私が仕事をする場所には、命名規則、アーキテクチャ、活用するフレームワークなどを含む標準があります。しかし、最近、より多くのスタイルを検討することについて多くの批判がありました。

たとえばif、複数行と1行でステートメントを記述する場合、たとえばの??代わりにc＃null結合演算子を使用して== null、インデントなどのスペースの量を指定します。

私はこれが個人的なスタイルの選択にもっと入り始め、チームや会社全体で均一である必要はないようです。ある人が他の人がより明確に読むと考えるものはそうではないかもしれません。この「余分な」均一性に価値はありますか？

均一性は問題ではありません（それは良いことです）が、剛性や柔軟性に問題がある場合があります。均一性を追求する際に独断的になると、チームに与える害は、結果として生じる可能性のある均一性からもたらされる利益よりも大きくなる可能性があります。

最も重要なもの（命名および大文字の標準、インデント、改行、ブラケットの配置など）の基本スタイルを設定し、重要性の低いもの（ステートメント形式、括弧の周りの空白など）の推奨事項を設定することをお勧めします、そして残りを心配しないでください。

潜在的に何十人もの人々がその寿命の長年にわたってプロジェクトに取り組んでいるとき、スタイルをジャンプしなければならないとき、それは時々混乱します。執筆スタイルを少しだけ維持するさまざまな著者によってさまざまな章が書かれている本を読むことを想像してください。可能ですが、迷惑です。

ほとんどのIDEは最近スタイルを実施できるため、必要に応じて、選択したコーディングスタイルを指定するIDE設定ファイルを（プロジェクトのソースコードの一部として）配布し、全員がそれをインストールして使用しているコードをフォーマットすることができます。チェックイン時にコードを再フォーマット/スタイル設定する方法さえあると思います（まだ調査する必要はありませんが）。

私が見た不均一性の1つのケースは、適切性に関係なくすべてのプログラミング言語に適用される単一の標準を持つことです。

• gotoCのような言語がなくても落胆しtryますcatch。
• InitialCaps標準ライブラリが存在するJavaScriptでの名前の使用（MicrosoftのMFCおよびC＃など）initialLowerCase。

均一性が高すぎるとは思わない。ただし、コーディング標準の仕様が多すぎることがよくあります。オープニングブレースを別の行に配置することの利点は、せいぜい疑わしく、それについて議論したり、コードの表面的な問題を修正するのに費やした時間を上回ることはありません。

均一性には2つの引数があります。

• 集団所有権の促進。誰かが「赤ちゃん」が変更によって傷つけられることを恐れることなく、他の誰かのコードを編集できること。一種の「私たちはみんな一緒にいる」という考え方。

• 追加のしやすさ。他の場所で既に何かが行われている場合は、これを取り、おそらく再利用できます。特定の規則は、物事を読みやすくしたり変更したりするのに役立つことがあるので、これは私の心にとってもう一つの利点です。