私は最近のAIの卒業生（約2年）で、ささやかな操作に取り組んでいます。（主に部署の最初の「採用担当者」として）基本的な（読みやすいですか？）C＃コーディング標準のドキュメントを作成するのは、私に落ちました。
おそらく、私がソフトウェアエンジニアの中で最もジュニアな人だと説明する必要があると思いますが、実際に半分使えるものを作れるといいので、この仕事を楽しみにしています。私はインターネットをかなり広範囲に検索し、コーディング標準ドキュメントに含める必要がある/含めるべきではないものに関する記事を読みました。これは、いくつかの提案を求めるのに最適な場所のようです。
私は「物事を行うための最良の方法」についての意見の不一致の世界全体への扉を開く可能性があることを認識しています。私は、各プログラマーが個々のタスクを解決するための好ましい方法を持っているという否定できない事実を理解し、尊重しています。個々のコードを読みやすくするための標準（命名規則など）。
だからここに行く....何か提案？何かありますか？
回答:
で始まる
次に、そのベースラインとの相違点と追加事項を文書化します。
IDesignには、一般的に使用されるC＃コーディング標準ドキュメントがあります。フレームワーク設計ガイドライン第2版も参照してください。
皮肉なことに、実際の基準を設定することは簡単な部分です。
私が最初に提案するのは、他のエンジニアから、カバーする必要があると感じていること、および重要だと感じているガイドラインについての提案を引き出すことです。あらゆる種類のガイドラインを実施するには、人々からある程度の賛同が必要です。あなたが最もジュニアかシニアかを問わず、抵抗に遭遇するコードの記述方法を指定したドキュメントを突然それらにドロップした場合。
一連の提案を作成したら、フィードバックとレビューのためにチームに送信します。繰り返しになりますが、すべての人々にそれらを購入してもらいます。
すでに採用されている非公式のコーディング慣行があるかもしれません（例：メンバー変数の接頭辞、キャメルケース関数名）。これが存在し、ほとんどのコードがそれに準拠している場合、その使用を形式化するために費用がかかります。反対の基準を採用すると、たとえそれが一般的に推奨されているものであっても、その価値よりも悲しみの原因となるでしょう。
また、新しいコーディング標準を満たすために既存のコードをリファクタリングすることも検討する価値があります。これは時間の浪費のように思えるかもしれませんが、標準に適合しないコードがあると、さまざまなスタイルのマッシュマッシュになるため、逆効果になる可能性があります。また、特定のモジュールのコードが新しい標準に準拠する必要があるか、既存のコードスタイルに従う必要があるかどうかも、ジレンマに陥ります。
私は、コーディング標準/ベストプラクティスを社内で行う際の参照として、常にJuval Lowyのpdfを使用してきました。FxCop / Source Analysisに非常に近く従います。これは、標準に準拠していることを確認するためのもう1つの非常に貴重なツールです。これらのツールとリファレンスの間で、すべての開発者が従うことを気にせず、それらを実施できる優れた標準を考え出すことができるはずです。
他のポスターはベースラインにあなたを指摘しました、私が追加するすべてはあなたの文書を短く、甘く、そして要点にしたものです、「必要なもの」と「必要なもの」を区別するために大量のStrunkとWhiteを使用します」
コーディング標準文書の問題点は、誰も実際にそれらを正しく読むことができないこと、そしてそれらを読むとき、彼らはそれらに従わないことです。そのようなドキュメントが読み取られ、フォローされる可能性は、その長さに反比例します。
FxCopは優れたツールであることに同意しますが、これが多すぎると、プログラミングの面白さをすべて損なう可能性があるため、注意してください。
独自のコーディング標準を作成する場合は、MSの標準（またはSunの標準または...言語に応じて）を使用しないでください。手がかりは標準という言葉にあります。各組織が独自に書くことを決めていなかった場合、世界はコーディングするのがはるかに簡単な場所になります。チーム/プロジェクト/ロールを変更するたびに新しい「標準」のセットを学ぶことを誰が本当に考えているかは、誰の時間の有効な利用でもあります。あなたがするべき最も多くのことは重要なポイントを要約することですが、重要なことは人から人へと変わるので、私はそれを行うことはお勧めしません。コーディング標準についてもう2つ指摘したい点
これら2つの点は、誰もが同じように見えるコードを書いてほしいという私の願いに対する現実です。
次のドキュメントは非常に役に立ち、簡潔であることがわかりました。それはidesign.netサイトからのものであり、Juval Lowyによって作成されています
注意：上記のリンクは現在機能していません。.zipファイルを取得するには、電子メールアドレスを与える必要があります（ただし、マーケティングには使用しません...正直に）ここをクリックしてください
私はコーディング標準がメンバー変数にはm_を、パラメーターにはp_を、文字列には 'str'のような型にはプレフィックスを使用することを義務付けているところから始めたところです。したがって、メソッドの本体に次のようなものが含まれる可能性があります。
m_strName = p_strName;
恐ろしい。本当にひどい。
私はコードコンプリート2をリストに追加します（ここではジェフがファンの一種であることを知っています）...あなたがジュニア開発者であれば、この本は、最高の基盤を設定する方法であなたの心を設定するのに役立ちます。コード作成の実践とソフトウェアのビルドがあります。
私は自分のキャリアの後半に到達したと言わざるを得ませんが、それは私の職業生活におけるコーディングとフレームワーク開発について私が考える多くの方法を規定しています。
チェックアウトする価値があります;）
MicrosoftのStyleCopを標準として適用したくなります。ビルド時に強制できます。ただし、レガシーコードがある場合は、新しいコードでStyleCopの使用を強制します。
http://code.msdn.microsoft.com/sourceanalysis
最終的には、コードをクリーンアップするためのリファクタリングオプションがあります。
個人的には、IDesignがまとめたものが好きです。しかし、それが私が投稿している理由ではありません...
私の会社のトリッキーなビットは、すべての異なる言語を考慮に入れることでした。私の会社はこれだけではありません。C＃、C、アセンブリ（デバイスの作成）、SQL、XAMLなどを使用します。標準にはいくつかの類似点がありますが、通常はそれぞれが異なる方法で処理されます。
また、より高いレベルの基準は最終製品の品質に大きな影響を与えると私は信じています。例：コメントをいつどのように使用するか、例外が必須である場合（ユーザーが開始したイベントなど）、例外と戻り値のどちらを使用するか（またはいつ）、コントローラーコードとプレゼンテーションコードのどちらを決定する客観的な方法か、誤解しないでください。低レベルの標準も必要です（書式設定は読みやすくするために重要です！）全体的な構造に偏っています。
留意すべきもう1つの要素は、賛同と執行です。コーディング標準は素晴らしいです。しかし、誰もそれらに同意せず、（おそらくもっと重要なこととして）誰もそれらを強制しない場合、それはすべて無意味です。
Philips Medical Systems向けに公開したものとhttp://csharpguidelines.codeplex.comで公開したものの両方を書いたので、少し偏見があるかもしれませんが、コーディング標準の作成、保守、およびプロモーションには10年以上かかります。私は、意見の違いを念頭に置いて1つのCodePlexを記述しようとしましたが、導入部の大部分を特定の組織での対処方法に費やしました。それを読んでフィードバックを送ってください.....
ほとんどの場合、失敗するように設定されています。業界へようこそ。
私は同意しません-彼が文書を作成している限り、起こり得る最悪の事態はそれが誰もが忘れてしまうことです。
他の人がコンテンツに問題を抱えている場合は、彼らにそれを更新して彼らが望むものを示すように依頼することができます。そうすれば、それはあなたの皿から離れて、そして他の人は彼らの変化を正当化する責任があります。
私は最近、他の多くのソース（IDesign、Philips、MSDN）からのアイデアを含むEncodo C＃ハンドブックを見つけました。
別のソースはProfessional C＃/ VB .NETコーディングガイドラインかもしれません。
私はFrancesco Balenaの本「VBおよびC＃開発者のための実践的なガイドラインとベストプラクティス」の大ファンです。
それは非常に詳細であり、すべての重要なトピックをカバーしています。それはあなたにルールを与えるだけでなく、ルールの背後にある理由も説明し、2つの反対のベストプラクティスが存在する可能性がある反ルールも提供します。唯一の欠点は、.NET 1.1開発者向けに作成されたことです。
dotnetspider.comドキュメントを提案する必要があります。
それはどこでも役に立つ素晴らしい詳細なドキュメントです。
あなたはこれをチェックすることができます、C＃/。NET開発者向けのトップ7コーディング標準とガイドラインドキュメントhttp://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html これが役立つことを願っています
私もリシャーパーをフォローしています。また、スコットガスリーブログで言及されているガイドライン http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net .aspx および http://csharpguidelines.codeplex.com/releases/view/46280
私が作成するコードでは、一般に公開されているAPIの.NET Framework設計ガイドラインと、プライベートメンバーの大文字と小文字のインデントに関するモノコーディングガイドラインに従っています。Monoは.NETのオープンソース実装であり、彼らは彼らのビジネスを知っていると思います。
Microsoftのコードがスペースを浪費する方法が嫌いです。
try
{
if (condition)
{
Something(new delegate
{
SomeCall(a, b);
});
}
else
{
SomethingElse();
Foobar(foo, bar);
}
}
catch (Exception ex)
{
Console.WriteLine("Okay, you got me");
}Monoのガイドラインで奇妙に感じるのは、8スペースのタブを使用していることです。しかし、いくつか練習した結果、インデントの制限のようなものを適用することで、複雑なコードを書くのに役立つことがわかりました。
また、括弧を開く前にスペースを挿入する方法も気に入っています。
try {
if (condition) {
Something (new delegate {
SomeCall (a, b);
});
} else {
SomethingElse ();
Foobar (foo, bar);
}
} catch (Exception ex) {
Console.WriteLine ("Okay, you got me");
}ただし、同僚が嫌いな場合は、そのようなことを強制しないでください（Monoに貢献する意思がある場合を除きます;-)
p_strNameます。そのような嫌悪感で作業することを余儀なくされたときの痛みを10％軽減します。：O