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