コーディングガイドライン+ベストプラクティス？
クエリに直接当てはまる質問が見つからなかったので、これを新しい質問として投稿します。私を助けるかもしれない既存の議論があれば、それを指摘して質問を閉じてください。
質問：
C＃コーディングガイドラインについてプレゼンテーションを行いますが、コーディング標準に限定されるものではありません。
ですから、大まかな考えはありますが、優れたプログラミング手法に取り組む必要があると思います。なので内容はこんな感じになります。
基本的なコーディング標準-ケーシング、フォーマットなど。
グッドプラクティス-他のデータ構造に対するハッシュセットの使用、文字列と文字列ビルダー、文字列の不変性とそれらの効果的な使用など
本当に私はもっと良い習慣を追加したいと思います（特にパフォーマンスを改善するために）。それで、C＃で使用されるいくつかの良い習慣を聞きたいです。助言がありますか？？？ （大きな説明は必要ありません:)アイデアだけで十分です。）
ここにいくつかのヒントがあります：
- 静的分析にはFxCopを使用します。
- コーディングスタイルの検証にはStyleCopを使用します。
- 値型のセマンティクスが異なるため、IDE（go to Tools/Options/Environment/Fonts and Colors/Display Items and供給ユーザータイプ（列挙型）およびユーザータイプ（値タイプ）＃DF7120 [223、113、32]）のような値。
- 例外はコードにバグを表示する傾向があるため、IDEすべての例外で中断させます。（デバッグ/例外... /共通言語ランタイム例外に移動してチェックします） スロー）。
- プロジェクト設定：安全でないコードを禁止します。
- プロジェクト設定：エラーとしての脅威警告。
- プロジェクト設定：算術オーバーフロー/アンダーフローを確認します。
- 明確に定義された単一の目標に変数を使用します。
- マジックナンバーは使用しないでください。
- 短いメソッドを記述します。メソッドには、1レベルの抽象化のみを含める必要があります。
- メソッドが小さすぎることはありません（20行のメソッドはかなり大きいと見なされます）。
- メソッドは、不正な入力から自身を保護する必要があります。
- 型を不変にすることを検討してください。
- プラグマ警告を無効にして、コード内の警告を抑制しないでください。
- 悪いコードにコメントしないでください：それを書き直してください。
- 例外を飲み込む理由をコードで明示的に文書化します。
- 文字列を連結することのパフォーマンスへの影響に注意してください。
- Gotoステートメントは絶対に使用しないでください。
- 早く失敗し、早く失敗します。
私はMicrosoftの クラスライブラリを開発するための設計ガイドライン を使用しています。そして、私は最初からかなり良いと思います。
基本的なコーディング標準-一貫していることを確認してください。 msdnに関するこのドキュメント に記載されている規則に従わない場合でも。ここでは一貫性が本当に重要だと思います。
ユニットテスト-ここで間違いはありません。
セキュリティ-機密データを渡す場合に安全であることを確認することについて話します。
パフォーマンス-ご存知のように、私は個人的に、アプリケーションを正しく取得してからパフォーマンスを確認することが私がしていることだと感じています。私はコードを書くときにそれを心の奥底に持っているので、最後に来るのは少し微調整です。