クラスライブラリに "system namespaces"を使用することをお勧めしますか？クラスライブラリのシステム名前空間を使用するかどうか：良いか悪いか
サンプル：
namespace System.Web {
public static class RequestExtensions {
public static bool IsPost(this HttpRequest r) {
return string.Compare(r.HttpMethod, "POST", StringComparison.OrdinalIgnoreCase) == 0;
}
}
}
利点：（特に拡張メソッドのための）追加の使用条項を含める必要がないので、全ての直ライブラリへの参照を追加した後に利用可能になります。
ベストサンプルはNUnitExプロジェクト（NUnitのネームスペースを使用）です。
短所：潜在的な競合。
Iを競合、良いアイデアはないと思いますそれ以外の人は誰も言わないでください。BADアイデア。ネームスペースは、多くのレベルの組織ツールです。他の企業と競合することなく独自の目的のために識別子を再利用できるだけでなく、異なる企業があなたの製品を他の誰かのものから分離することを可能にします。コードをSystem名前空間に入れると、あなたの型を使う人にとっては非常に混乱することがあります。
さらに、System名前空間内のものは、マイクロソフトから提供された完全で文書化された、コミュニティで検証された良好で信頼できるテスト済みのものであることが分かります。それは、同じ名前空間にコードを貼り付けることによって、あなたのコードがそれほど良いと主張しているだけでなく、そのコードに従わなければならないということです。
非常に悪い。それは混乱しており、絶対に必要な場合にのみ行うべきです（必要な場合があります）。
これは100％必要な場合にのみ実行します。「便宜」のためだけに使用しないでください。
システムベースの名前空間を使用すると、誰かがあなたのコードを拾い上げ、それが何をしているか把握することが難しくなる可能性があります。例えば、私が新しいC＃を拾うと、私は何かを知らないときに "System.Web.xyz"のようなグーグルで終わることがよくあります。
この場合、「System.Web.RequestExtensions」がSystem.Web名前空間の実際のメンバーではないことがわかりますので、存在しないクラス。
基本的に、私の見解では、を本当にうまく文書化する必要があるか、またはと別の名前空間を見つける必要があります。
私はそれは、Microsoftがフレームワークの次のバージョンでRequestExtensionsクラスを作成することを決定します可能性があるため、それは名前を防ぐために、お客様の会社名と名前空間を開始するために、常に良い方法です
設計ガイドラインを約namespace naming話：
次のように名前空間名の一般的な形式は次のとおりです。たとえば
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]を、Microsoft.WindowsMobile.DirectXが。
異なる企業の名前空間が同じ名前と接頭辞を持つことを避けるために、名前空間の接頭辞には会社名を付けることをお勧めします。
ここSystemまたはMicrosoftを再利用するための余地はありません。
+1 BAD - 潜在的な名前clnflicts。 – adatapost