提问



我一直在运行StyleCop而不是一些C#代码,它一直报告我的using指令应该在命名空间内。[81]


是否存在将using指令放在命名空间内而不是命名空间外的技术原因?

最佳参考


两者之间实际上存在(微妙的)差异。想象一下,你在File1.cs中有以下代码:


// File1.cs
using System;
namespace Outer.Inner
{
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}


现在想象有人将另一个文件(File2.cs)添加到项目中,如下所示:


// File2.cs
namespace Outer
{
    class Math
    {
    }
}


编译器在查看命名空间外的那些using指令之前搜索Outer,因此它找到Outer.Math而不是System.Math。不幸的是(或者幸运的是?),Outer.Math没有PI成员,所以File1现在已经被破坏了。


如果将using放在命名空间声明中,则会发生这种情况,如下所示:


// File1b.cs
namespace Outer.Inner
{
    using System;
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}


现在编译器在搜索Outer之前搜索System,找到System.Math,一切都很好。


有些人认为Math对于用户定义的类可能是一个坏名称,因为System中已经存在一个;这里的重点是是 a差异,它会影响代码的可维护性。


注意如果Foo在名称空间Outer而不是Outer.Inner中会发生什么也很有趣。在这种情况下,在File2中添加Outer.Math会破坏File1,无论在何处using。这意味着编译器在查看任何using指令之前搜索最里面的封闭命名空间。

其它参考1


这个帖子已经有了一些很好的答案,但我觉得我可以通过这个额外的答案带来更多细节。


首先,请记住带有句点的名称空间声明,例如:


namespace MyCorp.TheProduct.SomeModule.Utilities
{
    ...
}


完全等同于:


namespace MyCorp
{
    namespace TheProduct
    {
        namespace SomeModule
        {
            namespace Utilities
            {
                ...
            }
        }
    }
}


如果你愿意,你可以在所有这些级别上加上using指令。 (当然,我们希望using只在一个地方,但根据语言是合法的。)


解析哪种类型的隐含规则可以这样松散地说明:首先搜索匹配的最内部范围,如果找不到任何内容,则将一个级别输出到下一个范围并在那里搜索,并且依此类推,直到找到匹配为止。如果在某个级别找到多个匹配项,如果其中一个类型来自当前程序集,则选择该类型并发出编译器警告。否则,放弃(编译时错误)。


现在,让我们在两个主要惯例的具体例子中明确这意味着什么。


(1)在外面使用:


using System;
using System.Collections.Generic;
using System.Linq;
//using MyCorp.TheProduct;  <-- uncommenting this would change nothing
using MyCorp.TheProduct.OtherModule;
using MyCorp.TheProduct.OtherModule.Integration;
using ThirdParty;

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    class C
    {
        Ambiguous a;
    }
}


在上面的例子中,为了找出Ambiguous的类型,搜索顺序如下:



  1. C中的嵌套类型(包括继承的嵌套类型)

  2. 当前命名空间MyCorp.TheProduct.SomeModule.Utilities
  3. 中的类型
  4. 命名空间MyCorp.TheProduct.SomeModule
  5. 中的类型
  6. MyCorp.TheProduct
  7. 中的类型
  8. MyCorp
  9. 中的类型
  10. null 命名空间(全局命名空间)中的类型

  11. SystemSystem.Collections.GenericSystem.LinqMyCorp.TheProduct.OtherModuleMyCorp.TheProduct.OtherModule.IntegrationThirdParty
  12. 中的类型


另一个惯例:


(2)内部使用:


namespace MyCorp.TheProduct.SomeModule.Utilities
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using MyCorp.TheProduct;                           // MyCorp can be left out; this using is NOT redundant
    using MyCorp.TheProduct.OtherModule;               // MyCorp.TheProduct can be left out
    using MyCorp.TheProduct.OtherModule.Integration;   // MyCorp.TheProduct can be left out
    using ThirdParty;

    class C
    {
        Ambiguous a;
    }
}


现在,按以下顺序搜索类型Ambiguous:



  1. C内的嵌套类型(包括继承的嵌套类型)

  2. 当前命名空间MyCorp.TheProduct.SomeModule.Utilities
  3. 中的类型
  4. SystemSystem.Collections.GenericSystem.LinqMyCorp.TheProductMyCorp.TheProduct.OtherModuleMyCorp.TheProduct.OtherModule.IntegrationThirdParty
  5. 命名空间MyCorp.TheProduct.SomeModule
  6. 中的类型
  7. MyCorp
  8. 中的类型
  9. null 命名空间(全局命名空间)中的类型



(注意MyCorp.TheProduct是3.的一部分,因此在4.和5.之间不需要。)


结束语


无论你是将命令放在命名空间声明的内部还是外部,总有可能以后有人将具有相同名称的新类型添加到具有更高优先级的命名空间之一。


此外,如果嵌套命名空间与类型具有相同的名称,则可能会导致问题。


将使用从一个位置移动到另一个位置总是很危险的,因为搜索层次结构发生了变化,可能会找到另一种类型。因此,选择一个约定并坚持下去,这样你就不必使用它。


默认情况下,Visual Studio的模板将命名空间的使用放在之外(例如,如果让VS在新文件中生成新类)。


使用外部的一个(微小的)优点是,您可以将using指令用于全局属性,例如[assembly: ComVisible(false)]而不是[assembly: System.Runtime.InteropServices.ComVisible(false)]

其它参考2


将它放在命名空间中会使该文件命名空间的声明属于文件(如果文件中有多个命名空间),但如果每个文件只有一个命名空间,那么无论它们是在外面还是在外面都没有多大区别在命名空间内。


using ThisNamespace.IsImported.InAllNamespaces.Here;

namespace Namespace1
{ 
   using ThisNamespace.IsImported.InNamespace1.AndNamespace2;

   namespace Namespace2
   { 
      using ThisNamespace.IsImported.InJustNamespace2;
   }       
}

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

其它参考3


根据Hanselman - 使用指令和装配......以及其他此类文章,技术上没有区别。[82]


我的偏好是将它们放在命名空间之外。

其它参考4


根据StyleCop文档:


SA1200:UsingDirectivesMustBePlacedWithinNamespace


原因
C#using指令放在namespace元素之外。


规则说明
如果将using指令或using-alias指令放在namespace元素之外,则会违反此规则,除非该文件不包含任何名称空间元素。


例如,以下代码将导致两次违反此规则。


using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}


但是,以下代码不会导致违反此规则:


namespace Microsoft.Sample
{
    using System;
    using Guid = System.Guid;

    public class Program
    {
    }
}


此代码将干净地编译,没有任何编译器错误。但是,目前还不清楚正在分配哪种版本的Guid类型。如果在命名空间内移动using指令,如下所示,将发生编译器错误:


namespace Microsoft.Sample
{
    using Guid = System.Guid;
    public class Guid
    {
        public Guid(string s)
        {
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            Guid g = new Guid("hello");
        }
    }
}


代码在以下编译器错误上失败,在包含Guid g = new Guid("hello");的行上找到


CS0576:命名空间Microsoft.Sample包含与别名Guid冲突的定义


该代码创建了一个名为Guid的System.Guid类型的别名,并且还创建了自己的类型,称为Guid,具有匹配的构造函数接口。稍后,代码将创建Guid类型的实例。要创建此实例,编译器必须在Guid的两个不同定义之间进行选择。当using-alias指令放在namespace元素之外时,编译器将选择在本地名称空间中定义的Guid的本地定义,并完全忽略在名称空间外定义的using-alias指令。遗憾的是,这在阅读代码时并不明显。


但是,当using-alias指令位于命名空间内时,编译器必须在同一命名空间中定义的两种不同的,冲突的Guid类型之间进行选择。这两种类型都提供了匹配的构造函数。编译器无法做出决定,因此它会标记编译器错误。


将using-alias指令放在命名空间之外是一种不好的做法,因为它可能会导致这种情况混淆,在这种情况下,实际使用的是哪种类型的版本并不明显。这可能会导致可能难以诊断的错误。


在namespace元素中放置using-alias指令会将其作为bug的来源消除。



  1. 多个命名空间



在单个文件中放置多个名称空间元素通常是一个坏主意,但是如果这样做,最好将所有using指令放在每个名称空间元素中,而不是全局放在文件的顶部。这将严格限定命名空间的范围,并且还有助于避免上述类型的行为。


重要的是要注意,当使用位于命名空间之外的using指令编​​写代码时,在命名空间中移动这些指令时应小心,以确保这不会改变代码的语义。如上所述,在namespace元素中放置using-alias指令允许编译器以指令放置在命名空间之外时不会发生的方式在冲突类型之间进行选择。


如何修复违规行为
要修复违反此规则的行为,请在namespace元素中移动所有using指令和using-alias指令。

其它参考5


当您希望使用别名时,在命名空间内放置使用语句会出现问题。别名不会从早期的using陈述中受益,必须完全合格。


考虑:


namespace MyNamespace
{
    using System;
    using MyAlias = System.DateTime;

    class MyClass
    {
    }
}


与:


using System;

namespace MyNamespace
{
    using MyAlias = DateTime;

    class MyClass
    {
    }
}


如果您有一个冗长的别名,例如以下(这是我发现问题的方式),这可能会特别明显:


using MyAlias = Tuple<Expression<Func<DateTime, object>>, Expression<Func<TimeSpan, object>>>;


使用命名空间内的using语句,它突然变为:


using MyAlias = System.Tuple<System.Linq.Expressions.Expression<System.Func<System.DateTime, object>>, System.Linq.Expressions.Expression<System.Func<System.TimeSpan, object>>>;


不漂亮。

其它参考6


正如Jeppe Stig Nielsen所说,这个主题已经有了很好的答案,但我认为这个相当明显的微妙之处也值得一提。


using在命名空间内指定的指令可以使代码更短,因为它们不需要完全限定,因为它们在外部指定时。


以下示例有效,因为类型FooBar都在同一个全局命名空间中Outer


设定代码文件 Foo.cs :


namespace Outer.Inner
{
    class Foo { }
}


并且 Bar.cs :


namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}


这可能会省略using指令中的外部命名空间,简而言之:


namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

其它参考7


在答案中讨论了技术原因,我认为最终涉及个人偏好,因为差异不是 big ,而且两者都存在权衡。 Visual Studio的创建.cs文件的默认模板使用名称空间之外的using指令,例如


通过在项目文件的根目录中添加stylecop.json文件,可以调整stylecop以检查名称空间外的using指令,如下所示:


{
  "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json",
    "orderingRules": {
      "usingDirectivesPlacement": "outsideNamespace"
    }
  }
}


您可以在解决方案级别创建此配置文件,并将其作为现有链接文件添加到项目中,以便在所有项目中共享配置。

其它参考8


如果您的源解决方​​案中使用的默认使用ie references 应位于命名空间之外且new added reference< 是一个很好的做法,你应该把它放在命名空间里面。这是为了区分正在添加的引用。