対処する名前空間にglobal ::を使用する

Question

私が理解しているように、global::修飾子を使用すると、同じ名前の別の名前空間に隠された名前空間にアクセスすることができます。 MSDN pageは、例としてSystemを使用しています。独自の名前空間Systemを作成した場合は、元にはglobal::Systemという名前を付けることができます。まず頭に浮かんだことは、誰が名前空間をSystemと呼ぶのですか？このページは明らかに推奨されていませんが、大きなプロジェクトでは名前空間の重複は非常に可能です。これが起こったときに、物事が間違った方向に向いているというサインか、衝突する名前空間を持つ有効な理由がありますか？

Answer 1

名前空間が競合する正当な理由の1つは、以前のバージョンの.Net用に作成された社内ライブラリの使用で、それ以降のバージョンで追加された機能は含まれていない可能性があります。たとえば、.Net 1.1日間に、APIレジストリ呼び出しをラップしたRegistryクラスを作成しました。純粋なチャンスで、私が選んだメソッド名は、.Net Registryクラスのメソッド名とまったく同じで、まったく同じことをしたので、私の自宅のコードを簡単に外すことができました。より複雑なものについては、修飾子がglobal::の古いコードを使用すると便利です。

既存の.Net名前空間を使用して意図的に新しいコードを命名することは、間違いなくコードの匂いになります。

Answer 2

一般に、global::は、「名前空間構造の先頭から始めたい」という意味で使用されます。 MyProduct.Systemという名前空間がある場合、MyProduct名前空間に存在するものは、Microsoft System名前空間にアクセスすることはできません。それはコードのにおいですか？たぶん時々、しかし特に臭いではありません。

Answer 3

マシン生成コードでは、認識しない名前空間の競合の可能性を最小限に抑えるため、global::を試してみる必要があります。さらに、コンフリクトを起こす可能性のあるコードは、より具体的に使用することができます。

Answer 4

あなたの名前空間の1つに別の名前があることが時々起こると思います。たとえば、私は名前空間.Persistence.NHibernateを持っています。ここで、NHibernateはNHibernateアセンブリのルート名前空間でもあります。

私はそれだけでisses命名だ、ここで任意のコードのにおいが表示されません。）

Answer 5

Microsoftは優秀な本Framework Design Guidelines 2nd Ed.でいくつかの良い名前空間のガイドラインを持っています。一般的には、コンフリクトを導入することを推奨します（たとえば、タイプStreamの名前を付けるなど）。

私はglobal ::修飾子を使用したことはないと思います。私は一般的にそれがコードのにおいであると考えています（例外はありますが、MusiGenesisとsixlettervariablesが指摘しています）。