I recently stopped using using-statements and instead use the full namespace path of any .net object that I call.
Example:
using System;
namespace QuizViewer
{
class Class1
{
Console.WriteLine("Hello World!");
}
}
This is what I do now.
namespace QuizViewer
{
class Class1
{
System.Console.WriteLine("Hello World!");
}
}
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?
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.
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.
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(...) :)
Short answer no: it is the same code that is compiled.
I think that this style result in a programmer performance decrease :). I use the using statement and usually it is clear from code to which namespace the class belong. If not, press F12.
Just my 2c.
There's no performance impact; it's mostly a stylistic choice. I find that using using statements reduces the clutter. Plus, with Intellisense, it's easy enough to see the fully qualified namespace.
The only performance hit, is the hit you take to type it all out, and with you or others reading it.
Using statements are to help readability, not really for performance.
If you disassemble both of this pieces of code and look at IL code, you'll find that compiler always references all the types by it's full names. That is absolutely identical ways to operating types.
Related
I'm taking a C# course on Udemy. In this course, there is a section where they discuss "working with files". He teaches us how to use the .IO namespace and its classes, however I don't know what it does, how it can be used, and when it should be used (examples of real world applications).
Can someone please explain to me what the .IO namespace and it's classes (like fileinfo) are used for, and when we can apply it (in simple terms(I'm only a beginner)). Thank you!
The System.IO namespace contains types for working with I/O. So, whenever you want to input something or output something, you will almost certainly use it.
And since pretty much everything will at some point either need some input or provide some output, if only for debugging purposes, the real-world applications of System.IO is "pretty much every .NET code ever written".
For example, almost every programmer will, at some point in their life, have written the following program:
class HelloWorld
{
static void Main()
{
System.Console.WriteLine("Hello World");
}
}
Well, System.Console.WriteLine simply delegates to System.IO.TextWriter.WriteLine, so whenever you have written a Hello World program, you have used System.IO.
I read somewhere that when you add using System; to your .cs file, the compiler (or maybe something else) adds all System related classes to your .cs file and so maybe it is better to not always add using System; and instead reference your DateTime with its full namespace like this: System.DateTime, for example, if it is easy enough to do and few things reference System it in your .cs file.
Is that true and if so, can that hurt performance or increase the size of the app? If so, I realize that using System; is easier to write and is a convenience and so therefore, you must weigh convenience with performance. It also might be the case that only adding a using System; might not make much difference but when many references are added, maybe it could? Thanks!
Both using directive and full namespace generate the same IL.
It might be very tiny bit of extra work for Language compiler, but you want to sacrifice for readability.
Overview of the compile-time and runtime processes diagram is from Illustrated C# 2012 by Daniel Solis
Mention like
System.Console.WriteLine("Something");
this easy to Understanding purpose Only. But Developer Point of Each Time don't mention fully Qualify Names.
So That Time using Namespaces Using.System
If you use "using System;" you have access to all methods inside the System class.
Your class has a "link" to all of System.
If you write "using System.DateTime;" as example you only have access to the DateTime functions.
In my opinion it is better to use the specified using like "using System.DateTime".
With that you don't have links to "uneccessary" classes/methods in your .cs file.
Also the "using System" does not include all Methods that are inside of the System.
Examples for this are the IO class or the Xml Class.
If you want to use these you have to write "System.IO." before your method call or you have to write using System.IO;
When should I use full name, Sytem.Guid.NewGuid();? Should I always use using System; and then Guid.NewGuid(); for all cases?
you should use the later, i.e. include namespace first. The advantage of it is by only seeing the using statements, you will be well aware that which libraries are used in this file.
I think it will make more sense to use fully qualified name i.e. Sytem.Guid.NewGuid() if you have duplicate names at some level of class/namespace hierarchy which you want to avoid by explicitly telling the full name.
As System is pretty much unique namespace you should go for Guid.NewGuid()
I'd say consistency is more important than which alternative you choose. Personally I tend to always specify using directives and keep them sorted alphabetically, so it's really immediate to see what is or isn't there. Then in my code I always use unqualified names, except when I need to disambiguate between classes with the same name.
I personally don't like this long identifiers. The code is very hard to read if you have a lot of them.
However, when there are ambiguities between type names, the fully qualified version resolves this. I personally only use them when I have to, due to namespace conflicts. And also in this case I like more to declare a namespace aliase. This makes the code much more readable.
Anyway, for the compiled app, it makes no difference, the compiled code is the same.
What I also have encountered, that they were unpractical for some mannual refactoring action, but maybe the opposite may also be true, I don't remember the exact case...
Doesn't really make a difference, I think. 'Using' is more useful when coding, but when compiling to IL, all classes get compiled to their full name.
Namespaces are a compile-time only feature of C# that allow you to save time during development. The using directives are utilized by the compiler to look up shorthand Type names in your code.
Basically each time the compiler encounters a type name in your code that it does not know it takes each using directive and prepends it to the type's name and sees if that fully qualified name resolves.
Once you application is compiled the namespaces and the using directives are gone as the IL does not need them.
To answer your question it really doesnt matter.. if you are using it often in a single file then import it else use the fully qualified namespace
edit typos
Hi,
This is possibly a moronic question, but if it helps me follow best practice I don't care :P
Say I want to use classes & methods within the System.Data namespace... and also the System.Data.SqlClient namespace.
Is it better to pull both into play or just the parent, ie...
using System.Data
using System.Data.SqlClient
or just...
using System.Data
More importantly I guess, does it have ANY effect on the application - or is it just a matter of preference (declaring both the parent and child keeps the rest of the code neat and tidy, but is that at the detriment of the application's speed because its pulling in the whole parent namespace AND then a child?)
Hope thats not too much waffle
It doesn't make any difference to the compiled code.
Personally I like to only have the ones that I'm using (no pun intended) but if you want to have 100 of them, it may slow down the compiler a smidge, but it won't change the compiled code (assuming there are no naming collisions, of course).
It's just a compile-time way of letting you write Z when you're talking about X.Y.Z... the compiler works out what you mean, and after that it's identical.
If you're going to use types from two different namespaces (and the hierarchy is largely illusional here) I would have both using directives, personally.
Click Organize->Remove Usings and Visual Studio will tell you the correct answer.
Firstly, it has no effect on the application. You can prove this by looking at the CIL code generated by the compiler. All types are declared in CIL with their full canonical names.
Importing namespaces is just syntactical sugar to help you write shorter code. In some cases, perhaps where you have a very large code file and are only referring to a type from a specific namespace a single time, you might choose not to import the namespace and instead use the fully-qualified name so it's clear to the developer where the type comes from. Still, though, it makes no difference.
Express what you mean and aim for concise, clear code - that's all that matters here. This has no effect on the application, just on you, your colleagues and your future workers brains.
Use whatever happens when write your type name and press Ctrl + .,Enter in VS.
In my background in C++ I was a supporter of using the scope resolution operator, for example
class Foo
{
std::list<int> m_list;
...
}
for external libraries, to keep clear which library you were using.
Now in C# I don't know if there's a rule of thumb or a best practice to know which packages should be included via the using keyword and which classes should be fully qualified. I suppose that this can be a subjetive issue, but would like to know the most extended practices.
I pretty much never fully qualify names - I always use using directives instead.
If I need to use two names which clash, I'll give both of them aliases:
using WinFormsTextBox = System.Windows.Forms.TextBox;
using WebFormsTextBox = System.Web.UI.WebControls.TextBox;
That rarely comes up though, in my experience.
I tend to make autogenerated code fully qualify everything though, just for simplicity and robustness.
I think the saving grace in C# is the directives are fully constrained to the file you place them in. I use them whenever their use is clear for the code in the file and it helps readability of the code. Another team at my office doesn't use them at all - I think it's nuts but they came up with their own rules and are happy with them.
Tend towards whatever makes the code more readable and understandable.
If the name may be ambiguous and their is no common "most likely case" then fully/partially qualifying to make this clear can be sensible even if this increases verbosity.
If confusion exists but one candidate is far more likely then qualify only in those cases where you do not use the most common case.
Common example is the use of System.Collection.X classes rather than the System.Collections.Generics versions (perhaps for back wards compatibility). In this case importing the generic namespace is fine and any non generic ones are fully qualified.
This makes it clear where you are using legacy code.
If you will be dealing with multiple clashes and the resulting full qualification would make you code extremely unreadable then it may make sense to use aliases to separate them out but you should be pretty averse to doing this since it renders the resulting code easier to physically read but harder to conceptually understand.
You have injected an element of inconsistency with the wider world. this makes code snippets within the class harder to understand in isolation.
If you must do this consider alias names which make it very clear that these are aliases as an indication to readers that they should look at the using statements for confirmation of the real types.