10

C# でプライベート メソッドとプライベート スタティック メソッドに名前を付ける最もスマートな方法を見つけようとしています。

背景: プライベート メンバーのベスト プラクティスは、アンダースコア プレフィックス + キャメルケースであることを知っています。これについて私に異論を唱えることもできますが、この規則に従うハードコアなプロのコードを十分に見たことがあると信じてください。これは熟練した業界標準です。

また、パスカル ケースがパブリック メソッドの業界標準であることも知っています。しかし、private および private static メソッドに対して、パスカル ケース、キャメルケース、およびアンダースコア プレフィックス + キャメルケースへのテスト スタイルの命名 (つまり、 method_must_return_false_occasionally ) の組み合わせを見てきました。

しかし、C# でのプライベートおよびプライベートな静的メソッドの命名のベスト プラクティス スタイルは何ですか?

一部のプライベートメソッドから使​​用され、他のメソッドでは使用されない特定のスタイルがある場合、それは理解できます。説明してください。

読んでくれてありがとう。

4

6 に答える 6

17

Microsoft の命名ガイドラインと Brad Abram のStyle Guideを確認してください。

彼らは、すべてのメソッドは PascalCase であるべきだと言っています

public void DoWork() {}
private void StillDoWork() {}
private static void ContinueToDoWork() {}
于 2009-04-04T17:57:07.653 に答える
7

.NET クラス ライブラリ開発の命名ガイドラインでは、パブリックとプライベートの使用法を区別しておらず、静的メソッドにはPascalケースを推奨しています。

EDIT : 私の個人的な慣行は、メソッドとプロパティに Pascal ケーシングを使用し、フィールド、パラメーター、およびローカル変数にキャメル ケーシングを使用することです。クラス内からインスタンス メンバーを参照this.する場合、必要に応じてクラス メンバーやパラメーターと区別するために使用します。「筋金入りのプロ」の資格があるかどうかはわかりませんが、報酬は得ています。:-)

EDIT 2：これを最初に書いて以来、私は仕事を変えました。私たちが従うコーディング標準は、私の個人的な感覚とは異なり、プライベート フィールドの前にアンダースコアを付けています。私は ReSharper も使い始めましたが、私たちの標準は (一般的に) デフォルトのルールに従っています。アンダースコアで簡単に生活できることがわかりました。thisコード標準に適合しないため、絶対に必要な場合にのみ使用します。一貫性は個人の好みに勝ります。

于 2009-04-04T18:00:22.373 に答える
3

業界標準についてはわかりませんが、プライベート メソッドでも Pascal ケーシングを使用しており、静的メソッドを区別していません。

于 2009-04-04T17:59:10.737 に答える
2

このweird_underscore_naming規則は通常、テストを読みやすくするためにテストに限定されており、BDD によって強く推奨されています。メソッドが何をするかを簡潔に説明するのに対し ( DepositMoney)、テストは何をしているのかを説明する必要があることを覚えておいてください。つまり、Negative_deposits_must_be_caught

于 2009-04-04T18:44:16.417 に答える
1

1 つの選択肢は、 style copなどの一貫性を保つためのツールを使用することです( reSharperを使用する場合は、 codeplexに style cop のプラグインがあります)。ほとんどのツールは、Microsoft のガイドラインを強制 (? 示唆) しているように見えます。これは、コードの MS プラットフォーム承認を取得するためのいくつかのテストを通過するためです。

于 2009-04-04T18:19:33.810 に答える
1

私が働いてきた各場所は、常に異なったやり方をしてきました。

プロの開発者として、プロの一部は、異なるコーディング規約を持つ可能性のある新しいチームに適合することだと思います。

自分のスタイルを切り替えて、最初の数週間で生じる認知的不協和に対処できることは、職業の一部です。

さまざまなオープンソースなどのプロジェクトに目を向けると、さまざまなスキームが見られるでしょう。

また、アンダースコアの camelCase と Pascal のケースの議論が、コミュニティや、時にはチームを分割するのを見てきました。これが、コーディング スキームのポイントだと思います。

したがって、プロジェクトがあなただけの開発者である場合を除いて、あなたは自由です - チームの他のメンバーが何を使用したいのか、チームが理解しやすくするものを見つけてみてください.

私が考慮に入れるもう1つのことは、これが単純なプロジェクトまたは複数のパターンを持つ複雑なオブジェクト指向設計であるか、またはIOCを使用している場合、オブジェクト指向用語でのコードの複雑さです。その後、さまざまなタイプのコーディング標準で「スパイク」を実行し始めます。次に、それを使用しているときにコードが物理的にどのように見えるかを見てください。あなたとチームにとって見栄えがするか、それとも醜く見えるかです。

于 2009-04-04T18:30:20.087 に答える