我应该同意禁止“；使用“；指令

本文关键字：指令 使用 禁止 我应该 | 更新日期: 2023-09-27 17:47:49

我的同事坚持在代码中显式指定命名空间，而不是使用using指令。换句话说，每当代码中出现这种类型时，他都希望为每种类型使用完全限定的名称。类似的东西

public class MyClass
{
    public static void Main()
    {
        System.Console.WriteLine("Foo");
    }
}

而不是：

using System;
public class MyClass
{
    public static void Main()
    {
        Console.WriteLine("Foo");
    }
}

后果可想而知。

他给出的专业：

  1. 将代码复制并粘贴到其他源文件中更简单
  2. 它的可读性更强（您可以立即看到名称空间）

我的缺点：

  1. 我得写更多
  2. 代码可读性较差（我想de gustibus non-disputeandum est）
  3. 没有人这么做

你对此怎么看？

我应该同意禁止“；使用“；指令

如果您需要复制和粘贴代码，以便真正受益于拥有完全限定的类型，那么您会遇到更大的问题。

此外，为了能够键入完全限定的类，您是否计划记住每个类都在哪个命名空间中？

对于略有不同的答案：LINQ。

扩展方法只能通过"using"语句获得。因此，无论是查询语法还是fluent接口，都只能使用正确的"using"语句。

即使没有LINQ，我也会说使用"using"。。。推理，你能用更少的字符理解得越多越好。有些名称空间很深，但对代码没有任何价值。

还有其他扩展方法（不仅仅是LINQ）也会受到同样的影响；当然，您可以使用静态类，但是fluent接口更具表现力。

我对此怎么看？

我认为，一个提出这样一个想法并以自己的方式证明这一点的人，很可能对C#语言和.NET开发有许多其他根本性的误解。

当你的同事说"复制并粘贴代码"时，他就失去了所有的可信度。

我发现不使用"using"指令的最大问题不是类的实例化和定义。它将值传递给在命名空间中定义的函数。比较这两段代码（VB.Net，因为这是我所知道的，但你会明白的）。

Module Module1
    Sub Main()
        Dim Rgx As New System.Text.RegularExpressions.Regex("Pattern", _
            System.Text.RegularExpressions.RegexOptions.IgnoreCase _
            Or System.Text.RegularExpressions.RegexOptions.Singleline _
            Or System.Text.RegularExpressions.RegexOptions.IgnorePatternWhitespace)

        For Each result As System.Text.RegularExpressions.Match In Rgx.Matches("Find pattern here.")
            'Do Something
        Next
    End Sub
End Module

这个

Imports System.Text.RegularExpressions
Module Module1
    Sub Main()
        Dim Rgx As New Regex("Pattern", _
            RegexOptions.IgnoreCase _
            Or RegexOptions.Singleline _
            Or RegexOptions.IgnorePatternWhitespace)

        For Each result As Match In Rgx.Matches("Find pattern here.")
            'Do Something
        Next
    End Sub
End Module

在这种情况下，使用了大量枚举，并在for循环中内联声明变量，以减少范围，在vb.Net的情况下不使用"using"或"imports"，可能会导致可读性非常差。

通过复制和粘贴使代码更容易移动只是一种不合逻辑的做法，很可能是潜在危险做法的警告信号。代码的结构和易读性不应该由编辑的方便性决定。

如果说它让代码可读性降低、更具体的话——就我个人而言，我对标准对象所在的地方不感兴趣，那就好比用他们的全名称呼你的同事，前缀是你工作场所的街道地址。

然而，有时它会使代码更可读，因此硬性规则不适用，只是常识。

因为我们在C#中有一个工具可以通过按下Ctrl+来自动设置using语句-我看不出有什么理由不使用它；"酷"；这里的内容是：

假设您有两个名称空间：

控制台命名空间1

和

控制台命名空间2

两者都有一个Console类。现在，只需一行代码就可以更改对ConsoleNamespace2的所有引用，这很酷。

我的建议是：如果可以的话使用using，如果必须的话使用完整的。我不认为完整的一个，如果更容易阅读的话。了解你的框架，这永远不会成为问题。

同样值得注意的是，像ReSharper这样的工具（为什么你还没有使用它？）会自动为你添加合适的"使用"行。

使用"using"的原因之一是它"告诉"任何阅读源代码的人你的类将要做的事情。例如，使用System.IO命令会告诉读者您正在执行I/O操作。

我的一般规则是，如果我要多次使用特定命名空间中的项，它会得到一个using指令。然而，我不想在文件的顶部使用我只使用过一两次的指令。

在您的机器上安装ReSharper。坐下来，让它引导你的同事走向正义。说真的，还有更大的战斗，但如果需要两分钟以上的时间来进行教育，这就是程序员应该避免的。

"当你的同事说"复制并粘贴代码"的那一刻，他就失去了所有的可信度。"同上。

"德米特定律说……"同上

我补充说。这太荒谬了，不使用using语句。找ReSharper，想办法教这个家伙如何做到这一点，如果它似乎没有生效——根据给出的原因，是时候开始寻找一份不同的工作了。仅仅是不使用using语句等概念之间的相关性就很可怕。如果这是一条规则的话，你将被困在每天16小时的工作中。不知道你接下来会面临什么其他类型的对常识和逻辑的冒犯。

但说真的，这甚至不应该用ReSharper这样的工具来提出来。金钱被浪费了，购买ReSharper，进行代码清理，然后重新制作可用的软件。：）那是我的2美分。

如果您重复复制和粘贴代码，这不意味着创建一个标准DLL来包含在每个项目中吗？

我以前使用过这两种方法的项目，不得不说，使用"using"语句对我来说很有意义，它减少了代码，使其更具可读性，编译器最终会以正确的方式优化代码。唯一可能出现问题的是，如果两个命名空间中有两个类具有相同的名称，则必须使用完全限定的名称。。。但这是例外，而非常规。

我认为，随着Visual Studio中的IntelliSense功能以及使用ReSharper等第三方产品，我们不再关心是否使我们的代码完全合格。在复制和粘贴代码时，解析名称空间不再耗时。

您也可以使用别名…：

using diagAlias = System.Diagnostics;
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            diagAlias.Debug.Write("");
        }
    }
}

我已经编码25年了。USINGS是必不可少的，应该始终使用，并且是一种良好的编码实践。然而，任何优秀的开发人员都应该有一个代码库。当包含完全限定的名称空间时，共享代码片段要容易得多。

评论COPY&PASTE是一种糟糕的技术，通常来自那些没有花时间构建强大的代码库，也没有停下来真正理解通用代码是经过测试的代码的开发人员。我认为完全限定的名称空间在代码存储库中是必要的，否则你会四处寻找，试图确定名称空间的来源。

天哪。一个步骤可能是教你的同事关于Ctrl+它会自动为您插入using语句。

我建议反对你同事的提议。对我来说，如果你没有一个很长的名称空间，阅读代码会容易得多。想象一下：

Namespace1.Namespace2.Namespace3.Type var = new Namespace1.Namespace2.Namespace3.Type(par1, par2, par3);

与相反

Type var = new Type(par1, par2, par3);

关于复制粘贴-您确实有Shift+Alt+F10来添加命名空间，所以这应该不是问题。

您真的想以这种方式维护代码吗？即使有了intellisense，所有的打字也不会有成效。

我称之为"copy-n-pape"，而不是"copy-n-存储"，因为在这个过程中，99.9%的代码被滥用。所以，这就是我对你同事提出的这种方法的第一个理由的回答。

顺便说一句，当你把需要的代码添加到代码中时，像Resharper这样的工具会在顶部添加using语句（所以即使你这样"复制"代码，你也可以很容易地做到）。

撇开个人偏好不谈，我认为你的理由比他的更有价值，所以即使假设它们都是有效的观点，我仍然建议在顶部写下使用声明。不过，我不会把它定为"禁令"，因为我认为编码标准是指导方针而不是规则。根据您的团队规模，可能很难强制执行这样的操作（或者缩进的空格数、缩进样式等）。

让它成为一个指导原则，这样所有其他开发人员都可以自由地用较短的版本重新命名完全限定的名称，随着时间的推移，代码库将符合该指导原则。要注意那些从工作中抽出时间来简单地将一种风格的所有出现都改变为另一种的人——因为如果你不做任何其他事情，那就不会很有成效。

他可能对某些人有意见。例如，在我工作的一家公司，我们有很多代码生成的类，因此我们所有的代码生成类都使用完全限定的类名称，以避免任何潜在的冲突。

符合所有标准。NET类，我们只使用using语句。

在类似的系统中。NET，在名称空间中有类型的地方，你必须做出决定：名称空间是名称的一部分，还是类型的组织工具？

有些系统选择第一个选项。然后，您的using指令将能够缩短您最常使用的名称。

在。NET，是后者。例如，考虑System.Xml.Serialization.XmlSerializationReader。观察命名空间和类型之间的重复。这是因为在这个模型中，类型名称必须是唯一的，即使在命名空间之间也是如此。

如果我没有记错，你可以在这里找到CLR团队描述的内容：http://blogs.msdn.com/kcwalina/archive/2007/06/01/FDGLecture.aspx

将代码复制并粘贴到其他源文件中更简单。

是的，但如果你复制/粘贴了很多代码，你可能做错了。

它更可读（您可以立即看到名称空间）

看到名称空间并不重要，因为至少当你遵循微软的指导方针时，类型名称已经是唯一的；命名空间并没有真正为您提供有用的信息。

我是一个倾向于完全限定名称空间的人。当我使用我不熟悉/很久没有使用过的组件时，我会这样做。我帮助我记住那个名称空间中的内容，所以下次我要查找它/相关的类。

这也有助于我了解项目中是否已经有合适的参考资料。就像我写《系统》一样。网状物UI，但找不到扩展，然后我知道我忘记了/谁设置了项目忘记放在ASP中。NET AJAX引用。

不过，这些天我用快捷键（Ctrl+.）来限定类，所以我做得越来越少了。如果你键入类的名称（大小写正确）并按下快捷键，你可以很容易地完全限定/添加using语句。

这对StringBuilder来说很好，我似乎从来没有系统。文本，所以我只需键入StringBuilder->Ctrl+。现在，我添加了用法。

德米特定律说你应该只使用一个点：

对于许多使用点作为字段标识符的现代面向对象语言，该定律可以简单地表述为"只使用一个点"。也就是说，代码"a.b.Method（）"违反了"a.Method（）"没有的法律。

当然，这并不总是切实可行的。但是长串的点分隔标识符违反了公认的做法。

编辑：这个答案似乎有争议。我提出Law of Demeter主要是作为风格指南，这里的大多数回复似乎都同意限制点数是个好主意。在我看来，jQuery（和JavaScript）存在可读性问题，部分原因是过多的点会渗透到任何不平凡的程序中。

Visual Studio在几乎所有文件的顶部都包含了大量using语句，这难道不是暗示using语句被认为是一种良好的做法吗？

相关文章：