使用语句与命名空间路径?C# [英] Using Statements vs Namespace path? C#

查看:15
本文介绍了使用语句与命名空间路径?C#的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我最近停止使用 s 而是使用任何 我调用的对象.

I recently stopped using using-statements and instead use the full namespace path of any .net object that I call.

例子:

using System;    

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

这就是我现在所做的.

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

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

Before you ask why I do this, I am using this style so that I can see exactly where my objects are coming from and it's easier when using the different Timer objects and other objects with similar names.

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

Is there any performance increase or decrease in this style of programming?

推荐答案

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

There is zero performance difference because the compiler ALWAYS puts in the full name - using is only a hint for the compiler, the runtime doesn't know or support that.

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

However, once you memorize where the objects come from you will look at this as silly and verbose. There is just so much noise and people just know that Path is from System.IO, Console is in System and StringBuilder is in System.Text.

您的方法的一个缺点:不使用,在当前命名空间之外没有扩展方法.享受编写 System.Linq.Enumerable.Where(inputSequence,...) 而不仅仅是 inputSequence.Where(...) 的乐趣 :)

One downside of your approach: Without using, no extension methods outside of the current namespace. Have fun writing System.Linq.Enumerable.Where(inputSequence,...) instead of just inputSequence.Where(...) :)

这篇关于使用语句与命名空间路径?C#的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆