【问题标题】:Using Statements vs Namespace path? C#使用语句与命名空间路径? C#
【发布时间】:2011-10-01 11:51:56
【问题描述】:

我最近停止使用s,而是使用我调用的任何 对象的完整命名空间路径。

例子:

using System;    

namespace QuizViewer
{
    class Class1
    {
        Console.WriteLine("Hello World!");
    }
}

这就是我现在所做的。

namespace QuizViewer
{
    class Class1
    {
        System.Console.WriteLine("Hello World!");
    }
}

在你问我为什么这样做之前,我使用这种样式是为了可以准确地看到我的对象来自哪里,并且在使用不同的 Timer 对象和其他具有相似名称的对象时更容易。

这种编程风格是否有性能提升或降低?

【问题讨论】:

  • 我会说这种风格会导致正在阅读或编写代码的的性能显着下降......(这样做很公平这适用于一些类,例如Timer,其中有几个同名的类,但在大多数情况下,我认为命名空间是噪音。)
  • 您始终可以将鼠标悬停在 Visual Studio 中的类型名称上以查看该类型的完整命名空间和类名。
  • 请注意,您说的是using 指令,而不是using statementsusing 语句using(var stream = File.Open(...)) { ... }的形式。
  • 另请注意,此相关问题可能会帮助您了解为什么此更改不会影响性能:stackoverflow.com/questions/6614375/…
  • 最后,请注意,如果您因为两个名称相似的事物之间的特定混淆而避免“使用”,您可以使用 using alias 指令using FrobTimer = BogoSoft.Froboznicator.Timer; - - 现在您可以在该文件中使用标识符FrobTimer,编译器将知道您的意思是完全限定类型。

标签: using-statement .net c# .net namespaces using-statement


【解决方案1】:

如果您反汇编这两段代码并查看 IL 代码,您会发现编译器总是通过其全名引用所有类型。这与操作类型的方式完全相同。

【讨论】:

    【解决方案2】:

    性能差异为零,因为编译器总是输入全名 - using 只是编译器的提示,运行时不知道或不支持。

    但是,一旦你记住了这些对象的来源,你就会认为这很愚蠢和冗长。噪音太大了,人们只知道 Path 来自 System.IO,Console 在 System 中,StringBuilder 在 System.Text 中。

    您的方法的一个缺点:不使用,在当前命名空间之外没有扩展方法。写System.Linq.Enumerable.Where(inputSequence,...) 而不仅仅是inputSequence.Where(...) 玩得开心:)

    【讨论】:

    • 对于一个Where(),它仍然可以忍受。但是更复杂的查询很快就会变得难以辨认。
    【解决方案3】:

    唯一的性能损失是您将其全部输入并在您或其他人阅读时所受到的影响。

    使用语句是为了提高可读性,而不是真正的性能。

    【讨论】:

      【解决方案4】:

      没有性能影响;这主要是一种风格选择。我发现使用using 语句可以减少混乱。此外,借助 Intellisense,可以轻松查看完全限定的命名空间。

      【讨论】:

        【解决方案5】:

        我认为这种风格会导致程序员的性能下降:)。我使用 using 语句,通常从代码中可以清楚地看出该类属于哪个命名空间。如果没有,请按 F12。
        只是我的 2c。

        【讨论】:

        • 在这种情况下,你如何在按下 F12 之前“告诉”它是哪个计时器? System.Timers.Timer _timer; System.Threading.Timer _timer2; System.Windows.Forms.Timer _timer3;
        • 将鼠标悬停在 Timer 类型名称或其实例上以查看完整类型名称。
        • 只是想继续...从我的角度来看,在 C# 中到处使用 var 而不是声明强类型变量确实是一种糟糕的样式代码...
        • @platon 在 C# 中使用 var 不会阻止变量被强类型化。来自MSDN - “重要的是要理解 var 关键字并不意味着“变体”,也不表示变量是松散类型或后期绑定的。它只是意味着编译器确定并分配最合适的类型。”
        • 确实,我同意,我自己可能表达得很糟糕。我不喜欢看到所有变量都声明为 var 的代码。对于没有编写此代码的程序员来说,这是一场噩梦。以这种方式编写的代码读起来很糟糕,我总是想改变它...... :-)
        【解决方案6】:

        简短回答否:编译的代码相同。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 2013-11-23
          • 1970-01-01
          • 1970-01-01
          • 2015-05-14
          • 1970-01-01
          • 2010-11-08
          • 1970-01-01
          相关资源
          最近更新 更多