C# コーディング標準/ベスト プラクティスのドキュメントを作成するための提案はありますか?[閉まっている]

StackOverflow https://stackoverflow.com/questions/14967

  •  08-06-2019
  •  | 
  •  

質問

私は AI を卒業したばかり (約 2 年目) で、ささやかな業務に従事しています。基本的な (役に立つと思われる?) C# コーディング標準ドキュメントを作成するのは、(主に私がその部門の最初の「採用者」であるため) に任されました。

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

私は、「物事を行うための最善の方法」についての意見の相違が存在する世界への扉を潜在的に開いていることを認識しています。私は、各プログラマーにはそれぞれのタスクを解決するための好みの方法があるという否定できない事実を理解していますし、尊重しています。そのため、私は個人的な才能を抑圧するほど厳しく戒律的なものを書くつもりはなく、一般的な方法論を取得しようと努めることに同意しました。標準（例:命名規則) を使用して、個々のコードを読みやすくします。

それで、ここに行きます...助言がありますか？まったくありますか？

役に立ちましたか？

解決

から始めます

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

他のヒント

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

皮肉なことに、実際の基準を設定するのは簡単な部分になりそうだ。

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

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

すでに非公式のコーディング慣行が採用されている可能性があります (例: メンバー変数の接頭辞、キャメルケース関数名など)。これが存在し、ほとんどのコードがそれに準拠している場合は、その使用を正式化する価値があります。たとえそれが一般的に推奨されているものであっても、反対の基準を採用すると、その価値以上に大きな悲しみを引き起こすことになります。

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

私はいつもJuval Lowy'sを使っています pdf コーディング標準/ベストプラクティスを社内で行う際の参考として。それは非常に近いところに続きます FXコップ/ソース分析, 、これは標準が遵守されていることを確認するためのもう 1 つの貴重なツールです。これらのツールとリファレンスの間で、すべての開発者が従うことを気にせず、それを強制できる優れた標準を考え出すことができるはずです。

他の投稿者はベースラインを示していますが、私が付け加えたいのは、「必須」と「あったらいいのに」を区別するためにストランクとホワイトを大量に使用して、文書を短く、わかりやすく、要点を絞ったものにすることだけです。 」。

コーディング標準文書の問題は、誰も実際に文書を正しく読んでおらず、読んでも従わないことです。 このような文書が読まれ、追跡される可能性は、その長さに反比例して変化します。

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

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

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

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

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

C# コーディング標準

注意:上記のリンクは現在無効になっています。.zip ファイルを入手するには、電子メール アドレスを伝える必要があります (ただし、電子メール アドレスはマーケティングに使用されません...)正直に言って）試してみてください ここ

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

m_strName = p_strName;

最悪。本当にひどい。

追加します コードコンプリート 2 リストへ (ジェフがここのファンであることは知っています)...あなたが若手開発者である場合、この本は、最善のコード記述方法とソフトウェア構築の基礎を築く方法で心を整えるのに役立ちます。

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

チェックしてみる価値があります ;)

Microsoft 独自のルールは優れた出発点です。FxCop を使用してそれらを強制できます。

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

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

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

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

個人的に私が好きなのは、 アイデザイン をまとめました。でも、それが私が投稿する理由ではありません...

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

また、基準が高いほど最終製品の品質に大きな影響を与えると考えています。例えば：コメントをいつどのように使用するか、例外が必須の場合（例:ユーザーが開始したイベント)、例外を使用するかどうか (またはいつ使用するか)、戻り値、コントローラー コードとプレゼンテーション コードをどちらにするべきかを判断する客観的な方法は何か、など。誤解しないでください。低レベルの標準も必要です (読みやすさには書式設定が重要です!)、私は全体的な構造に対して偏見を持っているだけです。

もう 1 つ留意すべき点は、賛同と強制です。コーディング標準は素晴らしいです。しかし、誰もそれらに同意せず、そして（おそらくもっと重要なことに）誰もそれらを強制しなければ、それはすべて無駄になります。

私がフィリップス メディカル システムズ向けに出版したものと、 http://csharpguidelines.codeplex.com 少し偏見があるかもしれませんが、私はコーディング標準の作成、維持、推進に 10 年以上携わってきました。私は意見の相違を念頭に置いて 1 つの CodePlex を書こうとしており、特定の組織で意見の相違にどう対処するかについて序論の大部分を費やしました。読んでフィードバックを送ってください....

SSW ルール

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

あなたは失敗するように仕組まれている可能性が高いです。業界へようこそ。

私は同意しません。彼が文書を作成している限り、起こり得る最悪の事態は、その文書が全員に忘れられることです。

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

最近見つけました Encodo C# ハンドブック, これには、他の多くのソース (IDesign、Philips、MSDN) からのアイデアが含まれています。

別のソースが考えられます プロフェッショナルな C#/VB .NET コーディング ガイドライン.

私はフランチェスコ・バレナの本の大ファンです」VB および C# 開発者のための実践的なガイドラインとベスト プラクティス".

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

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

私が提案しなければならないのは、 ドットネットスパイダー.com 書類。
どこでも役立つ、素晴らしく詳細なドキュメントです。

私は以前にJuvalのものを使用したことがあり、やりすぎではないにしても、それは通りましたが、私は怠け者なので、今はただ彼の意志に従うだけです リシャーパー.

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

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

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

友人、あなたには楽しい仕事が待っています。幸運を祈ります。他に何か必要なことがあれば聞いてください:)

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

私の標準はこれに基づいており、いくつかの調整と .NET 2.0 用の更新が加えられています (フィリップスの標準は .NET 1.x 用に書かれているため、少し古いです)。

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

私が書くコードでは、通常次のようになります .NET Framework 設計ガイドライン 公開されている API と モノラルコーディングガイドライン プライベートメンバーの大文字とインデント用. 。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 に貢献するつもりがない限り ;-)

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top