c# - C＃コーディング標準/ベストプラクティスドキュメントを開発するための提案はありますか？

Question

私は最近のAI卒業生（約2年）で、控えめな操作で働いています。基本的な（役立つ？）C＃コーディング標準ドキュメントを作成することは私に（主に私が部門の最初の「採用者」であるため）私に落ちました。

私はおそらく最も若いソフトウェアエンジニアだと説明する必要があると思いますが、実際に半分使用できるものを作成できるかもしれないので、このタスクを楽しみにしています。私はインターネットをかなり広範囲に検索し、コーディング標準文書に何を含めるべきか、何を含めるべきでないかについての記事を読みました。これは、いくつかの提案を求めるのに最適な場所のようです。

私は、「物事を行うための最良の方法」についての意見の不一致の世界全体への扉を開く可能性があることを認識しています。私は、各プログラマーが個々のタスクを解決するための好ましい方法を持っているという否定できない事実を理解し、尊重します。その結果、私は個人的な才能を抑えるほど厳格に規範的なものを書くのではなく、一般的な方法論を取得して同意することを目指しています個人のコードを読みやすくするための標準（命名規則など）。

だからここに行く....何か提案はありますか？何かありますか？

score 139 · Accepted Answer

まずは

Microsoftの.NETガイドライン： http： //msdn.microsoft.com/en-us/library/ms229042.aspx（.NET 4.5用に更新されたリンク）
MicrosoftのC＃ガイドライン： http： //blogs.msdn.com/brada/articles/361363.aspx。

次に、そのベースラインとの違いと追加を文書化します。

score 32 · Accepted Answer

IDesignには、一般的に使用される C# コーディング標準ドキュメントがあります。フレームワーク設計ガイドライン第 2 版も参照してください。

score 26 · Accepted Answer

皮肉なことに、実際の基準を設定するのは簡単な部分である可能性があります。

私の最初の提案は、他のエンジニアから、何をカバーする必要があると感じているか、どのガイドラインが重要であると感じているかについての提案を引き出すことです。あらゆる種類のガイドラインを実施するには、人々からのある程度の賛同が必要です。コードの書き方を指定したドキュメントを突然彼らにドロップすると、最年少であろうと年長者であろうと、抵抗に遭遇するでしょう。

一連の提案を作成したら、フィードバックとレビューのためにチームに送信します。繰り返しますが、すべての人にそれらを購入してもらいます。

非公式のコーディング手法がすでに採用されている場合があります (メンバー変数のプレフィックス、キャメルケース関数名など)。これが存在し、ほとんどのコードがそれに準拠している場合、その使用を形式化するためにお金がかかります。反対の基準を採用することは、それが一般的に推奨されているものであっても、価値以上の悲しみを引き起こすでしょう.

新しいコーディング標準に合わせて既存のコードをリファクタリングすることも検討する価値があります。これは時間の無駄のように思えるかもしれませんが、標準を満たさないコードを使用すると、さまざまなスタイルのごちゃまぜになってしまうため、逆効果になる可能性があります。また、特定のモジュールのコードを新しい標準に準拠させるべきか、既存のコードスタイルに従うべきかというジレンマに陥ります。

score 14 · Accepted Answer

社内でコーディング標準/ベストプラクティスを実行するときは、常に Juval Lowy のpdfを参照として使用してきました。これは、標準に従っていることを確認するためのもう 1 つの貴重なツールであるFxCop / Source Analysisに非常によく似ています。これらのツールとリファレンスの間で、すべての開発者が従うことを気にせず、それらを強制できる優れた標準を考え出すことができるはずです。

score 9 · Accepted Answer

他のポスターはベースラインを示しています。私が追加するのは、ドキュメントを短く、甘く、要点に合わせて作成することです.Strunk and Whiteを大量に使用して、「必需品」と「それがあればいいのに」を区別します. "。

コーディング標準文書の問題点は、誰も実際に読んでいないことと、読んだとしても従わないことです。そのようなドキュメントが読まれてフォローされる可能性は、その長さに反比例します。

FxCop が優れたツールであることに同意しますが、これが多すぎると、プログラミングの楽しみがすべて失われる可能性があるため、注意してください。

score 9 · Accepted Answer

独自のコーディング標準を作成しないでください。MS のもの (または Sun のものなど、言語に応じて) を使用してください。手がかりは標準という言葉にあります。各組織が独自に作成することを決めていなければ、世界ははるかに簡単にコーディングできる場所になるでしょう。チーム/プロジェクト/役割を変更するたびに新しい一連の「標準」を学ぶことが、誰の時間の有効活用であると本当に考えている人がいるでしょうか。あなたがすべきことは、重要なポイントを要約することですが、重要なことは人によって異なるため、それを行うことはお勧めしません. コーディング標準について、他に 2 つの点を指摘したいと思います。

近いだけで十分 - コードが十分に近い限り、コーディング標準に従うようにコードを変更するのは時間の無駄です。
あなたが書いていないコードを変更する場合は、「ローカルコーディング標準」に従ってください。つまり、新しいコードを周囲のコードのように見せてください。

この 2 点は、誰もが同じように見えるコードを書いてほしいという私の願いに対する現実です。

score 8 · Accepted Answer

次のドキュメントは非常に役に立ち、簡潔であることがわかりました。これは idesign.net サイトからのもので、Juval Lowy によって作成されています。

C# コーディング標準

注意: 上記のリンクは現在無効です。.zip ファイルを取得するには、メールアドレスを提供する必要があります (ただし、マーケティングには使用しません... 正直なところ)ここで試してください

score 5 · Accepted Answer

私は、コーディング標準がメンバー変数にm_、パラメーターにp_、文字列に'str'などの型にプレフィックスを使用することを義務付けている場所から始めました。したがって、メソッドの本体に次のようなものがある可能性があります。

m_strName = p_strName;

最悪。本当にひどい。

score 5 · Accepted Answer

Code Complete 2をリストに追加します (Jeff がここのファンのようなものであることは知っています)。コード作成の実践とソフトウェア構築があります。

私は自分のキャリアの中で少し遅れてそれに到達したと言わざるを得ませんが、私の職業生活におけるコーディングとフレームワーク開発についての多くの考え方を支配しています.

チェックアウトする価値があります;）

score 4 · Accepted Answer

個人的には、IDesignがまとめたものが好きです。しかし、それは私が投稿している理由ではありません...

私の会社でのトリッキーな点は、すべての異なる言語を考慮に入れることでした。そして、私は私の会社がこれだけではないことを知っています。C＃、C、アセンブリ（デバイスを作成）、SQL、XAMLなどを使用します。標準にはいくつかの類似点がありますが、通常、それぞれが異なる方法で処理されます。

また、基準が高いほど、最終製品の品質に大きな影響を与えると思います。例：コメントを使用する方法とタイミング、例外が必須の場合（ユーザーが開始したイベントなど）、例外と戻り値を使用するかどうか（またはいつ）、コントローラーコードとプレゼンテーションコードのどちらを使用するかを決定する客観的な方法は何ですか？誤解しないでください。低レベルの標準も必要です（読みやすさにはフォーマットが重要です！）私は全体的な構造に偏っています。

覚えておくべきもう1つの要素は、賛同と執行です。コーディング基準は素晴らしいです。しかし、誰もそれらに同意せず、（おそらくもっと重要なことに）誰もそれらを強制しない場合、それはすべて無駄です。

score 4 · Accepted Answer

Microsoft独自のルールは優れた出発点です。FxCopでそれらを強制することができます。

score 4 · Accepted Answer

Philips Medical Systems 向けに発行されたものとhttp://csharpguidelines.codeplex.comにあるものの両方を書いたので、少し偏見があるかもしれませんが、コーディング標準の作成、維持、促進に 10 年以上携わっています。私は意見の違いを念頭に置いて 1 つの CodePlex を作成しようとしましたが、導入の大部分を特定の組織での対処方法に費やしました。それを読んで、私にフィードバックを提供してください.....

score 4 · Accepted Answer

Microsoft の StyleCop を標準として強制したくなるでしょう。ビルド時に強制できます。ただし、レガシーコードがある場合は、新しいコードで StyleCop の使用を強制するだけです。

http://code.msdn.microsoft.com/sourceanalysis

最終的には、コードをクリーンアップするためのリファクタリングオプションが追加されます。

http://blogs.msdn.com/sourceanalysis/

score 2 · Accepted Answer

SSWのルール

これには、いくつかの C# 標準と、さらに多くの標準が含まれています。主に Microsoft 開発者に焦点を当てています。

score 1 · Accepted Answer

私は最近Encodo C# Handbookを見つけました。これには、他の多くの情報源 (IDesign、Philips、MSDN) からのアイデアが含まれています。

別の情報源として、Professional C#/VB .NET Coding Guidelinesがあります。

score 1 · Accepted Answer

ほとんどの場合、失敗するように設定されています。業界へようこそ。

私は同意しません。彼がドキュメントを作成している限り、起こりうる最悪の事態は、ドキュメントが全員に忘れられることです。

他の人がコンテンツに問題を抱えている場合は、彼らが好むものを表示するように更新するよう依頼できます。そうすれば、それはあなたのプレートから外れ、他の人は変更を正当化する責任があります。

score 1 · Accepted Answer

C#/.NET 開発者向けのトップ 7 コーディング標準とガイドラインドキュメントhttp://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html をご覧ください。

score 1 · Accepted Answer

私は以前に Juval を使用したことがありますが、やり過ぎではないにしてもそれはスルーですが、私は怠け者で、Resharperの意志に従うだけです。

score 1 · Accepted Answer

dotnetspider.comドキュメントを提案する必要があります。
これは、どこでも役立つ優れた詳細なドキュメントです。

score 1 · Accepted Answer

私は Francesco Balena の著書「VB および C# 開発者向けの実用的なガイドラインとベストプラクティス」の大ファンです。

非常に詳細で、すべての重要なトピックをカバーしています。ルールを提供するだけでなく、ルールの背後にある理由を説明し、2 つの相反するベストプラクティスが存在する可能性がある反ルールも提供します。唯一の欠点は、.NET 1.1 開発者向けに書かれていることです。

score 1 · Accepted Answer

私たちのコーディング標準全体は、大まかに「StyleCop を使用する」と書かれています。

score 1 · Accepted Answer

これを参照してください: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx。

score 0 · Accepted Answer

ここで、既にリンクされている MS ガイドラインが優れた出発点であるという他のコメントを繰り返していると思います。私は自分のコードを主にそれらに基づいてモデル化しています。

私のマネージャーは過去に、あまり熱心ではないと言っていたので、これは興味深いです:D

友よ、あなたには楽しい仕事が待っています。頑張ってください。さらに何か必要な場合はお尋ねください:)

score 0 · Accepted Answer

私が書くコードでは、一般に公開されている API については.NET Framework の設計ガイドラインに従い、プライベートメンバーのケーシングとインデントについてはMono Coding Guidelinesに従います。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 に貢献する意思がある場合を除きます ;-)

score 0 · Accepted Answer

私もResharperをフォローしています。また、スコット・ガスリーのブログ 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

score 0 · Accepted Answer

Philips Medical Systems の標準はよく書かれており、ほとんどが Microsoft のガイドラインに従っています: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

私の標準はこれに基づいており、いくつかの調整と .NET 2.0 用の更新が行われています (Philips の標準は .NET 1.x 用に作成されているため、少し古くなっています)。

c# - C＃コーディング標準/ベストプラクティスドキュメントを開発するための提案はありますか？

26 に答える 26

Related

Reference