ソリューションのフォルダーは名前空間と一致する必要がありますか？

ソリューションのフォルダーは名前空間と一致する必要がありますか？

私のチームプロジェクトの1つに、プロジェクト内に多数のサブフォルダーがあるクラスライブラリがあります。

プロジェクト名と名前空間：MyCompany.Project.Section。

このプロジェクト内には、名前空間セクションに一致するいくつかのフォルダーがあります。

• フォルダーVehiclesのMyCompany.Project.Section.Vehicles名前空間にクラスがあります
• フォルダーClothingのMyCompany.Project.Section.Clothing名前空間にクラスがあります
• 等

この同じプロジェクト内に、別の不正なフォルダがあります

• フォルダーBusinessObjectsのMyCompany.Project.Section名前空間にクラスがあります

このような「組織の便宜」のためにフォルダが作成されるいくつかのケースがあります。

私の質問は：標準は何ですか？クラスライブラリでは、フォルダーは通常名前空間の構造と一致していますか、それとも混合バッグですか？

また、組み込みテンプレートを使用してクラスをフォルダーに追加する場合、デフォルトでは、フォルダー階層を反映する名前空間に配置されます。

クラスは見つけやすく、それだけで十分な理由になります。

私たちが従うルールは次のとおりです。

• プロジェクト/アセンブリ名は、.dllの末尾を除いて、ルート名前空間と同じです。
• 上記のルールの唯一の例外は、.Coreで終わるプロジェクトで、.Coreは削除されます
• フォルダは名前空間と等しい
• ファイルごとに1つのタイプ（クラス、構造体、列挙型、デリゲートなど）により、適切なファイルを簡単に見つけることができます

番号。

私は、小規模なプロジェクトと大規模なプロジェクトの両方で、単一の（私）と開発者のチームの両方で両方の方法を試しました。

最も単純で最も生産的な方法は、プロジェクトごとに単一の名前空間を持つことであり、すべてのクラスがその名前空間に入ることがわかりました。その後、クラスファイルを任意のプロジェクトフォルダに自由に配置できます。名前空間が1つしかないため、常にファイルの先頭にusingステートメントを追加する必要はありません。

ソースファイルをフォルダーに整理することは重要です。私の意見では、すべてのフォルダーを使用する必要があります。これらのフォルダーも名前空間にマップする必要はなく、作業が増えます。追加の負担が混乱を助長するため、実際には組織に有害であることがわかりました。

たとえば、次のFxCop警告を見てください。

CA1020：タイプ
が少ない名前空間は避けてください：グローバル名前空間以外の名前空間に含まれるタイプが5つ未満です https://msdn.microsoft.com/en-gb/library/ms182130.aspx

この警告は、新しいフォルダーの作成を正当化する4つの類似のクラスができるまで、新しいファイルを一般的なProject.Generalフォルダー、またはプロジェクトルートにダンプすることを推奨します。それが起こることはありますか？

ファイルを見つける

受け入れられた答えは、「クラスを見つけやすくなり、それだけで十分な理由になるはずです」と述べています。

答えは、プロジェクトが単一の名前空間を持つプロジェクトではなく、フォルダー構造にマップされない複数の名前空間をプロジェクトに持つことに関するものだと思います。

いずれの場合も、名前空間からクラスファイルが含まれているフォルダーを特定することはできませんが、[定義に移動]またはVisual Studioの検索ソリューションエクスプローラーボックスを使用してフォルダーを見つけることができます。また、これは私の意見ではそれほど大きな問題ではありません。それを最適化することを正当化するためにファイルを見つける問題に、開発時間の0.1％も費やしません。

名前の衝突

複数の名前空間を作成すると、プロジェクトに同じ名前の2つのクラスを含めることができます。しかし、それは本当に良いことなのでしょうか？おそらくそれを不可能にするほうが簡単でしょうか？同じ名前の2つのクラスを許可すると、90％の時間が特定の方法で機能し、その後、突然、特別なケースが発生するという、より複雑な状況が発生します。別々の名前空間で定義された2つのRectangleクラスがあるとします。

• クラスProject1.Image.Rectangle
• クラスProject1.Window.Rectangle

ソースファイルに両方の名前空間を含める必要があるという問題が発生する可能性があります。次に、そのファイルのすべての場所に完全な名前空間を書き出す必要があります。

var rectangle = new Project1.Window.Rectangle();

または、厄介なusingステートメントをいじくります：

using Rectangle = Project1.Window.Rectangle;

プロジェクトに単一の名前空間があると、別の名前を付けざるを得なくなります。私は、次のようなよりわかりやすい名前を付けます。

• クラスProject1.ImageRectangle
• クラスProject1.WindowRectangle

また、使用方法はどこでも同じです。ファイルで両方のタイプを使用する場合、特別なケースに対処する必要はありません。

ステートメントの使用

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

対

using Project1;

コードの作成中に常に名前空間を追加する必要がないことの容易さ。それは実際にかかる時間ではなく、それを行う必要があり、たくさんのusingステートメントでファイルを埋めるだけの流れの中断です-何のために？その価値はありますか？

プロジェクトのフォルダー構造の変更

フォルダーが名前空間にマッピングされている場合、プロジェクトフォルダーのパスは各ソースファイルに効果的にハードコードされます。つまり、プロジェクト内のファイルまたはフォルダーの名前を変更または移動するには、実際のファイルの内容を変更する必要があります。そのフォルダー内のファイルの名前空間宣言と、そのフォルダー内のクラスを参照する他のファイル全体のステートメントの使用の両方。変更自体はツールを使用しても簡単ですが、通常、クラスが変更されていない多くのファイルで構成される大きなコミットが発生します。

プロジェクトに単一の名前空間を使用すると、プロジェクトのフォルダー構造を変更できますが、ソースファイル自体を変更する必要はありません。

Visual Studioは、新しいファイルの名前空間を、それが作成されたプロジェクトフォルダーに自動的にマップします。

残念ながら、名前空間を修正する手間は、それらを扱う手間よりも少ないと思います。また、Add-> Newを使用するのではなく、既存のファイルをコピーして貼り付ける習慣もあります。

Intellisenseとオブジェクトブラウザ

大規模なプロジェクトで複数の名前空間を使用することについての私の意見の最大の利点は、名前空間の階層にクラスを表示するツールでクラスを表示するときに、余分な編成があることです。ドキュメントも。プロジェクトに名前空間が1つしかない場合は、すべてのクラスがカテゴリに分割されるのではなく、単一のリストに表示されることは明らかです。しかし、個人的に私はこれが不足しているために困惑したり遅れたりしたことがないので、複数の名前空間を正当化するのに十分なほど大きなメリットはありません。

大規模なパブリッククラスライブラリを作成している場合は、おそらく、プロジェクトで複数の名前空間を使用して、アセンブリがツールやドキュメントできれいに見えるようにします。

.NET内の標準は、可能な場合はそうすることを試みることですが、ハードルールとして固執するために不必要に深い構造を作成することはしないと思います。私のプロジェクトは、名前空間==構造のルールを100％遵守していません。そのようなルールから抜け出すのは、よりクリーンで良い場合もあります。

Javaでは選択の余地はありません。理論的に機能するものと実際に機能するものの古典的なケースと呼んでいます。

@lassevk：これらのルールに同意し、もう1つ追加します。

ネストされたクラスがある場合でも、それらをファイルごとに1つずつ分割します。このような：

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

そして

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

はい。

最初に、名前空間をたどることで実際のコードファイルを見つけやすくなります（たとえば、誰かが裸の例外呼び出しスタックを電子メールで送信した場合）。フォルダーを名前空間と同期させないようにすると、大きなコードベースでファイルを見つけるのが面倒になります。

次に、VSは、親フォルダー構造と同じ名前空間を持つフォルダーに作成した新しいクラスを生成します。これに逆らって泳ぐことにした場合、新しいファイルを追加するときに毎日行う必要があるのはもう1つの配管作業だけです。

もちろん、これは言うまでもないことですが、xisフォルダー/名前空間の階層がどの程度深いかに注意を払う必要があります。

はい、そうするべきです。そうでなければ混乱を招くだけです。

標準は何ですか？

公式の標準はありませんが、従来はフォルダから名前空間へのマッピングパターンが最も広く使用されています。

クラスライブラリでは、フォルダーは通常名前空間の構造と一致していますか、それとも混合バッグですか？

はい、ほとんどのクラスライブラリでは、フォルダーは名前空間と一致しているため、組織化が容易です。