回答:
すべての要件の理由。このように、標準に従うことはある種のカーゴカルトにはならず、人々は、その理由がもはや適用されない場合は標準を変更するか、または理由が明らかに適用されない特定のケースで標準に違反することは問題ないことを知っています。
タブ対スペース！同僚の1人が誤って多くのタブをリポジトリにシフトするスペースにコミットすると、更新が狂ってしまいます
命名規則
編集：これにより、命名規則ではなく、ガイドラインの命名を意味します。
たとえば、ガイドラインはになりますAll boolean values should begin with Is/Can/Has/etc when possible。ルールはAll boolean values must start with Is
IsCanUpdateやなどのプロパティで終了しますIsHasChildren。確かに、それは間違っていますが、標準で定められています。そして、これが私のポイントです：これらのことを指定し始めたら、すべてのベースをカバーするか、そうでなければ標準がカバーしないか、ひどくカバーする何かにぶつかってから、間違ったものを書くか、または、標準を無視し始めます。どちらにしても、チームは負けます。
グループのコーディング標準には、対処する必要がある警告およびエラーのコンパイラオプションを含める必要があります。
プログラマーは自分のコードの警告を自由に増やすことができますが、他の誰かのコードを読んで作業することでコンパイラーから得られる出力が乱雑にならないようにベースラインが必要です。
そのような標準は、そうでなければ適合しない例外的なコードが存在する場合、プログラマがそのような警告を個別に無効にする方法にも対処する必要があります。
私が好きないくつかの標準（私はそれらがたくさんあることを知っていますが、それは私が好むものです）：
規格は、あなたがコードを最初に書いている少しを助けるコーディング、彼らは助ける多くの あなた、またはあなたの交換は、2年後にコードを更新する必要があります。
理想的な標準は、コード内の任意のページにジャンプし、最初の読み取りで何をしているのか正確に理解できるコードにつながります。
一方、arbitrary意的な標準が多すぎると、コードの記述の流れが混乱する可能性があります。ですから、提案されたコーディング規約のすべての項目は、次の2つの基準に対して評価されるべきだと思います。
どちらも当てはまらない場合、アイテムは任意であり、おそらく不要です
私が書いた標準には、次のものを含めます。
明確にするために：
ファイル構成：ファイル内のアイテムの固定順序を指定すると、チームは他のファイルを簡単にナビゲートできます。#definesや構造定義を見つけるために狩りをする必要はありません。
命名規則：一貫性のある命名により、読みやすくなります。ただし、過度に多くのルールを指定しすぎないようにしてください。これにより、書き込み可能性が損なわれます。
コード構造。中かっこの配置、インデントレベル、スペースとタブなど チームに最適なオプションを見つけて、それを守ります。
正確さのために：
問題の種類に固有のベストプラクティス：メモリの割り当て、同時実行、または移植性に関するルール。
「定数の正確性」、staticおよびの適切な使用volatileなど。
プリプロセッサマクロ、およびその他の簡単に悪用される言語の機能に関するルール。
コーディング標準には何が必要ですか？出来るだけ少なく。もっと少なく。そして正当化してください。
私はプロセスを必要としないカウボーイコーダーだからではなく、（おそらく）「おそらく'95年のどこかのネットでこれを見つけた」以上のロジックのない重いコーディング仕様を見たからです働く官僚的な悪夢。
一部の人々は、標準を上げていくと、コードの「品質」が向上し、おそらくその尺度が上がると信じているようです。それまでは、アーキテクチャ、パフォーマンス、常識、およびファイル内の行数よりも重要な他の多くのものを無視します。
いくつかの古き良き常識は見過ごせないでしょう。関係のない点（フォントの種類やサイズなどの項目は、私が見た中で最も極端なものの1つである）に労力を費やしているコーディング標準文書が多すぎます。
開発者グループにいる場合の最善の方法は、お互いに話し合ってコードを確認し、容認できるものについてコンセンサスを形成し、ガイドラインとして主要なポイントを書き留める必要があるが、まさにそのガイドライン。ガイドラインとの相違を正当化できない場合は、なぜそれを行っているのかを検討する必要があります。
結局のところ、明確で理解可能なコードは、レイアウトやタイポグラフィに関する厳格なルールよりも重要です。
他の人が述べたように、コードテストのカバレッジは重要です。私も見たいです：
プロジェクト構造。テストはコードの一部ですか、それとも別のプロジェクト/パッケージ/ディレクトリにありますか？UIコードはバックエンドのものと一緒に動作しますか？そうでない場合、どのように区分化されますか？
開発工程。コードの前にテストを書きますか？壊れたビルドの修正は開発よりも優先されますか？コードレビューはいつ行われますか？
ソースコード管理。何時にチェックインされますか？設計ドキュメントとテスト計画は改訂管理されていますか？いつ分岐し、いつタグ付けしますか？以前のビルドを維持しますか？
展開標準。ビルドはどのようにパッケージ化されますか？リリースノートには何が必要ですか？アップグレードスクリプトはどのように作成/制御/実行されますか？
命名規則、書式設定、および関数/メソッド/モジュールに含めることができる行の数についてのくだらないことはすべて忘れてください。1つのルール：既存のスタイルが編集中のすべてのものを使用します。誰かのスタイルが気に入らない場合は、コードレビューでそれを選択してください。唯一の例外はtabs-vs-spacesの場合です。これは、多くのエディター/ IDEが盲目的に一方を他方に変換し、すべての行が変更されたために変更履歴が破棄されるためです。
実際に対処する必要があるのは2つあると思います。同じ方法でアプローチすることはできないため、実際にはそれらを別々に検討しますが、両方とも重要だと思います。
私がコーディング標準の資格を得る技術的側面は、ハーブサッターとアンドレイアレクサンドレスクがC ++コーディング標準と同様です。コーディングスタイルの資格があるプレゼンテーション命名規則、インデントなどを含む
コーディング標準
純粋に技術的であるため、コーディング標準はほとんど客観的です。そのため、すべてのルールは理由によってサポートされる必要があります。私が各アイテムに言及した本では：
理由と例外は、理由と時期を要約しているため、非常に重要です。
タイトルは、レビュー中に作業するタイトルのリスト（チートシート）を持っているだけで十分であるように明確にしなければなりません。そして明らかに、アイテムをカテゴリ別にグループ化して、探しやすいようにします。
SutterとAlexandrescuは、C ++が毛むくじゃらだと見なされているにもかかわらず、わずか100項目のリストしか持っていませんでした;）
コーディングスタイル
この部分は一般的に客観的ではありません（そして完全に主観的です）。ここでの意図は、一貫性を保証することです。これは、メンテナーや新規参入者を支援するためです。
ここでは、インデントまたはブレースのスタイルが優れているという聖戦に参加したくないため、このフォーラムがあります。したがって、このカテゴリでは、コンセンサス>多数決>リーダーによるarbitrary意的な決定によって物事を行います。
書式設定の例については、芸術的スタイルのオプションのリストを参照してください。理想的には、プログラムがコードを書き直すことができるように、ルールは明確で完全でなければなりません（ただし、コードをコーディングすることはまずありませんが;））
命名規則については、クラス/タイプを変数/属性と簡単に区別できるようにします。
このカテゴリでは、次のように「対策」を分類しています。
その他？
そして最後の言葉として、コーディング標準で議論されることはめったにありませんが、おそらくそれは各アプリケーションに固有であるため、コード編成です。建築上の問題はおそらく最も顕著な問題であり、最初の設計を台無しにしてしまい、今から何年も悩まされることになります。おそらく、基本的なファイル処理のセクションを追加する必要があります。パブリック/プライベートヘッダー、依存関係管理、懸念の分離、他のシステムまたはライブラリとのインターフェース...
しかし、それらが実際に適用および実施されなければ、それらは何もありません。
コードレビュー中に違反が発生する必要があります。違反が未解決の場合、コードレビューは問題ありません。
明らかに、ルールを変更することは、リーダーから「先に進む」ことを意味します。
私は、フレームワーク設計ガイドラインの形式が好きです。これには、ガイドラインの一般的なセクションと理論的根拠が含まれています。最も有用な部分は、Do、Do Not、Avoid、Considerで始まる詳細です。
以下は、インターフェイスメンバを明示的に実装するセクションの例です。次の項目があります（説明のために理論的根拠を削除しました）。
避ける強い理由がない限り、明示的にインターフェイスメンバー実装することは
メンバーがインターフェイスを介してのみ呼び出されることを意図している場合は、インターフェイスメンバーを明示的に実装することを検討してください。
明示的なメンバーをセキュリティ境界として使用しないでください。
機能が派生クラスによって特殊化されることを意図している場合、明示的に実装されたメンバーと同じ機能を提供する保護された仮想メンバーを提供してください。
これにより、一般的なトーンが作成されます。回避と検討を使用すると、開発者が自分の判断を使用できるようになります。また、ルールではなくガイドラインであるため、開発者はそれらをより口当たりがよく、順守する可能性が高くなります。
例。すべてのルールを使用する、きちんと配置された、自明ではない、現実に近い例。コメント（必ずしもコードの一部ではない）例のどの部分がどの規則に従うか。
テンプレート。C ++の種類ではなく、コピーアンドペーストしてライブで満たすもの。コピー元の参照がある場合、24行の定型コメントを簡単に取得できます。
コーディング標準は実際にはいくつかの項目です。
コーディング規約
ベストプラクティス
例えば 試した後に空のキャッチを残さないでください
try { Foo(); } catch { //do nothing }
1）Foo（）によってスローされた例外がある場合、後続の関数でfooが成功したと見なされる他の問題が発生する可能性があります。
2）グローバルエラーハンドラーは、prodで発生した例外をサポートチームに通知しません
コーディング環境
コーディング標準は、紙に書かれた場合、非常に効果的です。Goのコーディング標準の公開方法が気に入っています。gofmtプログラムのテキストをフォーマットにフォーマットするツールがあります。コーディング形式に関する議論は、単にソースのパッチとして行われますgofmt。
フォーマットに必要なものについては、
if、関数本体、他の目的のステートメントブロック、他の（主にC言語）コードを読んでいるときに、変数/関数名がプロジェクトのコンテキストで直感的でない場合、または5レベルのインデントを超える場合、または関数が6つまたは7つ以上の引数をとる場合、または関数が繰り返し実行される場合画面に2〜3ページあると、コードを読んで理解することが非常に難しくなります。拡張/保守作業を行うように求められた場合、それは難易度を高めるだけです。gofmtすべてのプロジェクト（または言語）でプログラムを作成し、プロジェクトにコミットする前にすべてのソースコードファイルをそのプログラムで実行するように願っています。
Google JavaScriptスタイルガイドが気に入っています。
ガイドラインは簡潔ですが、必要な場合は詳細が記載されています。