148

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

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

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

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

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

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

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

このように「整理の都合」でフォルダを作るケースは少なくありません。

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

4

7 に答える 7

85

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

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

私たちが従う規則は次のとおりです。

  • プロジェクト/アセンブリ名は、末尾が .dll であることを除いて、ルート名前空間と同じです。
  • 上記のルールの唯一の例外は、末尾が .Core のプロジェクトで、.Core が取り除かれます。
  • フォルダは名前空間に等しい
  • ファイルごとに 1 つのタイプ (クラス、構造体、列挙型、デリゲートなど) により、適切なファイルを簡単に見つけることができます
于 2008-08-07T12:58:21.267 に答える
78

いいえ。

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

最も単純で生産的なルートは、プロジェクトごとに 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 ステートメントでファイルをいっぱいにするだけです-何のために? その価値はありますか？

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

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

プロジェクト内の単一の名前空間を使用すると、ソース ファイル自体を変更することなく、プロジェクト フォルダー構造を自由に変更できます。

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

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

インテリセンスとオブジェクト ブラウザ

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

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

于 2015-03-25T12:22:56.320 に答える
34

.NET 内の標準は、可能な場合はそれを実行しようとすることですが、厳密な規則としてそれに従うためだけに不必要に深い構造を作成しないことだと思います。私のプロジェクトのどれも、名前空間 == 構造規則に 100% 従うことはありません。時には、そのような規則から抜け出す方がクリーン/より良い場合もあります。

Java では選択肢がありません。これは、理論的に機能するものと実際に機能するものとの典型的なケースと言えます。

于 2008-08-07T12:58:13.997 に答える
25

@lassevk: 私はこれらの規則に同意し、もう 1 つ追加する必要があります。

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

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

と

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}
于 2008-09-11T03:45:56.137 に答える
6

はい。

まず、名前空間をたどることで実際のコード ファイルを見つけやすくなります (たとえば、誰かがネイキッド例外コール スタックを電子メールで送信した場合)。フォルダーが名前空間と同期しなくなると、大きなコードベースでファイルを見つけるのが面倒になります。

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

もちろん、これは言うまでもなく、xis フォルダー/名前空間の階層がどの程度深くなるかについて保守的であるべきです。

于 2008-08-07T12:57:13.390 に答える
5

そうでなければ、混乱を招くだけです。

于 2008-08-07T12:55:17.653 に答える
1

標準は何ですか？

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

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

はい、ほとんどのクラス ライブラリでは、整理しやすいようにフォルダーが名前空間と一致しています。

于 2018-07-15T07:00:30.890 に答える