.NET / C＃プロジェクトにとって、どのコーディング標準が重要だと思いますか？これは、そのような中括弧と間隔とペダントリーを扱うことから何でもありえます。または、.NET Frameworkのどの名前空間を避けるべきか、構成ファイルのベストプラクティスなど、より基本的な質問になる可能性があります。
単純に別の投稿である投稿を作成しないようにしてください。たとえば、中括弧に焦点を当てた投稿が1つあればよいでしょう。一方のスタイルと他方のスタイルをサポートするために2つは必要ありません。アイデアは、ペットの基準に投票することではなく、基準を作成する際に考慮すべきことを具体化することです。
回答:
ここに、.NET frameworkバージョン4.0のコーディング標準に関する公式のMicrosoftガイドがあります。
1.1の古いバージョンが必要な場合は、ここをクリックしてください。
彼らが言うように、私はこれを必ずしも「T」に追いかけるわけではありません。ただし、疑わしい場合は、これが現在の.NETフレームワークとの一貫性を保つのに最適な場所です。これにより、特定のプロジェクトの初心者であるかどうかに関係なく、誰でも簡単に作業できます。
StyleCopを見てみたいかもしれません。スタイルエラーがビルドを壊すように、いくつかのビルドシステムに組み込むこともできます。デフォルト設定は、MSがガイドライン（他の人が投稿したもの）に対して提案しているものとほぼ一致しています。
また、デフォルトで付属しているルールを変更することもできます。
マイクロソフトのガイドライン：
これをオフィスで採用しました。Lance Huntによって書かれており、かなり包括的なものです。
http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx
さまざまなソースからスタイルの共通セットを選択しようとしています。前に言及されなかったいくつか：
私は、SSW（オーストラリアのコンサルティング会社）が提供する標準を推奨する必要があります。
コーディングだけでなく、プロジェクト管理など...信じられないほど貴重なリソース。
次のアプリケーションを使用して、キャメルバックルール、メソッド名などのほかにコーディング標準を維持しています。
GhostDoc-各メソッドの上部に自動生成されたコメントを追加します。アプリケーションは、メソッドの初期の概要を提供します。（無料）
http://submain.com/products/ghostdoc.aspx
Resharper-コード分析とリファクタリング http://www.jetbrains.com/resharper/
StyleCop -TFSにチェックインする前の最終的なクリーンアップとして。（無料）
確立されたコーディング標準は嫌いです。彼らはすべて、いくつかの愚かな間違いをしないように言ったり、何らかの方法でコードをフォーマットする方法を教えたりすることに関心があります。これらはすべて些細なことです。
私はあなたが意味する、彼らは（メンバーのために_など）の使用に何ハンガリー・スタイル'プレフィックス、あなたの変数を小文字にする方法、事業者間で入れてどのように多くのスペースを教えてくれます、相反するアドバイス（例えば、あなたがCxyzクラスを呼び出すことはできませんが、必要がありますインターフェイスIxyzを呼び出します）、コードのレイアウト方法（変数をクラスの最上部または最下部に配置）
全体像はすべて役に立たない。
効果的で保守可能で読みやすいコードを書くために重要なことは、これらの標準では決して言及されていません。
たとえば、変数をクラスの上部または下部に配置しますか？さて、誰が気にします-重要なのは、機能領域ごとに変数をグループ化する場合です。それは重要です（その場所に20個の変数が散在しているのを見たことがあれば、これを知っているでしょう）
中括弧を特定の場所に置くように指示されます。大したこと！K＆RとANSIスタイルの両方のブラケットでコードを読むことができますが、それは問題ではありません。重要なのは、すべてのWindowクラスが何らかの形で区別されている場合（FormやDlgなどでサフィックスが付けられている場合）、どのファイルにウィンドウコードが含まれ、どのファイルが通常のオブジェクトであるかを確認できることです。
このようなものは、標準に通常含まれているマイナーなポイントよりもはるかに重要です。なぜこのように開発されたのかはわかりませんが、多くの場合、効果的で生産的なコーディングを妨げる大量のルールにすぎません。
私の標準では、コードとファイルの編成により重点を置いています。ファイルの検索場所を参照する特定の標準があります。たとえば、開発者以外の場合は、プロジェクトの1つを見て、必要なドキュメントファイルをすぐに取得できます。同様に、他のプロジェクトと同様の方法でプロジェクトコードをレイアウトしようとします（注：常に適切ではない可能性のある重度に禁止された方法ではなく、実用的です）。基本的に、必要に応じて変更できます。
要するに-彼らは私たちが一緒に働くのを助けるためにあり、常に従わなければならない一連の制限的なルールとしてではありません。
警告：以下のプラグマティズム -質問は、「適切な」中括弧スタイルなどについての議論を引き出すために語られているようです。私はそのナンセンスに時間を浪費することに我慢しません。
利益-チームの全員が同じスタイルを持ち、Microsoftのガイドラインに酷似していますが、Resharperの標準が実際に業界でより広く使用されており、（おそらく）改善されているものを反映しているいくつかの点が異なります。
チームが巨大なドキュメントや本を作成して参照するのに費やす時間が少ないほど、またはcurly braces他の悪意に悩まされるほど、より多くのコーディングが行われます。ReSharperは、入力時に名前とスタイルを強制します。できた 議論の終わり。議論の余地はありません。続けて。
つまり、古典的なCode Completeを読むことで、コーディング標準の背後にある理論的根拠を理解し、コードを通じて意味を効果的に伝えるための多くの優れた指針を提供できます。標準文書や検査プログラムではできません。
resharperができることを強化したい場合は、StyleCop for ReSharperプラグインでStyleCopを追加してください。前述のように、MSガイドラインとReSharperのデフォルトの間にいくつかの小さな矛盾があります。私はそれらについてReSharperと一緒に行きます。ただし、どちらを選択しても、結果をReSharper構成ファイルに保存し、チーム全体で共有して完了します。
（いいえ、私はReSharperの有償ではありません。ただの幸せな顧客です。他の多くの機能に加えて、基本的なスタイルの問題を標準文書やコードレビューシステムよりもコスト効率よく処理します。 ）