This question already has answers here:
Using Statements vs Namespace path? C#
(6 answers)
Closed 9 years ago.
What is the difference between defining a namespace by using keyword and simply giving the path to access the file wherever it is used ?? Does it cause any change in the internal working of the program, because the results seem to be the same
It doesn't have any impact other than code readability and resolving type ambiguity.
Say you have 2 namespaces SampleNamespace1 and SampleNamespace2 that both have MyClass class. In order for you to specifically identify which MyClass to use is to correctly use the namespace.
As long as you actually access the same namespace, there is no difference in the result. From the compiled code it's impossible to tell which way the namespace was specified.
Note that the namespace has nothing to do with the path of the file. They may be the same, but it's only the namespace statements that specify the namespace. To make it the same as the folder where the file lies, is only to make it easier to find the right file.
Yes, the result is the same, because there's no difference.
Using is for clarify which class do You want to use, if there exists two class with the same name in more namespaces.
If You want to use both, with using, You can also create aliases for namespaces too to shorten Your code.
No difference. except it make your code organizer because you don't write the full path every time.
one of it's advantages is when you have 2 or more classes with the same name but in different namespaces in that case you 'll need to write the full path for readability.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
For example, I name my file(console application) 'Hello', so do I have to write namespace Hello?If no, what is the purpose of adding namespace?
No, the namespace can be anything, they don't have to be the same as the filename. It is good practice to have the namespaces correspond to physical file paths (folders in your solution).
So if you have a file in .\Interfaces\ViewModels\Client, usually the namespace declaration in that file will be:
namespace DefaultNamespaceOfAssembly.Interfaces.ViewModels.Client { ... }
ReSharper even offers to fix up namespaces that are breaking this rule.
The purpose of the namespace is to
modularize your code by putting things that belong together (by functionality for example) in the same namespace,
reduce name collisions. Without namespaces importing an external library would result in hell if it were to contain classes with the same name as classes in your own code.
Probably there are more, but at first thought these come to mind, although these two should already be enough to justify their existance.
I name my file(console application) 'Hello', so do I have to write namespace Hello?
No, you can name it whatever you want.
If you're writing a library to be used by other code, and that library is the only (or main) source of types in that namespace, then it would be convenient to users for the DLL to have a name based on the namespace, because then they can easily remember that the UsefulTypes.CoolStuff classes all come from the UsefulTypes.CoolStuff.dll assembly. There's no rule that you have to do this, it can just be convenient if you do.
With applications this isn't anywhere near as useful; end-users don't care what namespaces you use and may not know what a namespace is. It might be useful if the application was a tool for .Net developers, but otherwise not.
If no, what is the purpose of adding namespace?
Exactly what it says; it's a space for names. By putting the names of classes, enums, delegates and structs into a namespace they are separated from other cases of the same name being used in other namespaces. You don't have to make sure that no library you used has something with the same name, unless you are actually going to use that thing with the same name.
When writing an application it keeps stuff from other assemblies out of your way. When writing libraries it's even more important, as it also keeps your stuff out of other people's way.
I was under review of team code. I observe they had used class ClassAby writing using AAA.BBB; at the upper portion of the class; also they have sometime used class ClassB by AAA.BBB.ClassB. There are two basic questions.
Is there any performance issue while using above scenario. What is recommended
When I declare namespace; are all classes get loaded of that namespace or not.
Please assist here. Thanks.
I'll answer these as best as I can, I don't have any sources on hand, just experience (maybe someone can help with that).
There is no performance issue with importing a namespace versus calling it directly. When the compiler runs through it, you can think of it as always being fully qualified in the end. The using statement for namespaces is more to assist the developer so they don't have to fully qualify it each time. In fact, for your ClassB example, it could be that there is a collision with multiple namespaces defining the same class name. For example, the Calendar class is both in System.Globalization and System.Web.UI, so you have to fully qualify one or the other when using them.
Generally, all code is compiled into an assembly by the project it's under. Referencing any code inside of the assembly will load all of the associated code. Note, however that the code isn't necessarily compiled for use by the JIT until it's actually called.
Namespaces are for organizing your code (while preventing name collisions). They have no bearing on performance at all.
Fully qualified names in code are distracting and noisy. I prefer to never have them. If there is a namespace conflict, a using alias can resolve that.
only for places where there is a conflict with there being two Class defined in different namespaces, and, even then, I'll still rather use a using to differentiate them:
using MyClassB=AAA.BBB.ClassB;
// :
var myClassB= new MyNS();
in terms of performance, you can see the answer here:
The using directive is only syntactic sugar that disappears during
compilation. Whether or not the namespace was included via using or
mentioned in a fully-qualified type name is totally irrelevant in the
resulting bytecode. Hence, there is no performance benefit at runtime
by using one or the other.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have proved to myself that the namespace is not required to compile and run an application. However, what are the dangers and pitfalls of not using a namespace? It creates layers that I am trying to avoid.
I know you're screaming but what about agile and abstraction so that 20 layers of abstraction exist between the code and the object. I'm not asking if it violates this or that flavor of the month agile thing. Just what, if any, real world issues come about by not using a namespace?
Edit:
Creating a stand alone class dll so no conflicts within the class project. Trying to avoid when I include it in other projects having to use full qualified name. myNamespace.myClass MyClass = new myNamespace.myClass();
From the comments it appears that naming conflicts are the biggest problem.
Guess I should use a using statement and buck up...
Namespaces have two principle uses:
First, they enable the consumers of your code to more easily understand, find and correctly use your code. There is a reason why the system diagnostic tools are in System.Diagnostics namespace. It's so that customers can know what the stuff in there is for.
Second, they are a mechanism for preventing name conflicts.
The first is actually by far the more important. Conflicts aren't that common. Still, they are possible and judicious use of namespaces prevents them.
If you don't care about your customers finding, understanding and using your code, and you don't have naming conflicts, then sure, skip using namespaces.
It creates layers that I am trying to avoid.
There are no real additional "layers" created. The namespaces purely allow a way for the types to be organized, and help prevent naming collisions as projects get larger and more libraries are used.
As far as the runtime is concerned, there are no namespaces - all types are fully qualified, and the namespace in C# just changes the type name. Leaving the namespace off just makes your type name more likely to conflict with other names, but will have no "real impact" on whether or not the code works, provided you don't use the same name more than once in your project, or use a name that's the same as a name of a type from a referenced assembly and imported via using.
Edit in response to comment:
What I mean by "it creates layers" is that when I create the object I have to add the namespace as a layer. (i.e. myNamespace.myClass MyClass = new myNamespace.myClass();) "
Note that this is only required if you don't have a using myNamespace; statement, or if you use multiple namespaces within the project. If you're always working within the project's default namespace, then you will not need to qualify the name.
It might be a good idea to compare what life without namespaces looks like. The C language does not support namespaces. And very early in its existence, the open() function was used to open files.
Which means that no C programmer may ever use the name "open" for their own function.
Painful isn't it?
Namespaces help you use short and descriptive names. They do not add layers, they only create longer names. That you can very easily write shorter, the using directive makes it easy.
You can end up with conflicts and isn't standard practice for C#. It won't truly hurt anything in the long run.
A conflict could arise if you named your class the same thing as another visible class. For instance, if you named your class Math and had a using System; using statement, there would be a conflict that would only be resolved by specifying System.Math.
Again, not the norm and not something that should be published outside of internal use, but it sounds like you already know that :)
What does this answer to another question mean?
Yes, creating a nested namespace is possible. However, I believe the
preferred methodology for something like this would be to create a
resource file
This gives you the added benefit of being able to change without a
code change, as well as to support multiple languages.
I am making a few namespaces and I want them to be all under one namespace (MyNamespace), but I don't feel like going and changing all the code to add nested interfaces, and naming them MyNamespace.N1 is not very compatible with intelli-sense.
Edit: My main problem is that namespace MyNamespace.N1 { } does not seem to work right with renames and stuff like that. Is it even a true nested namespace declaration?
Underlying Question: A namespace declaration with a period in it is two namespaces. Why, then, when I rename it, does it not act right with the rename. My question may be vague, but I have such a problem with it that I thought for sure a lot of other people would have run into it. If not, then just close it and I'll try to figure it out some other way.
I'm trying to figure out how to put all the namespaces in a project under one namespace. So you would access them using MyProject.MyN1.MyClass. If I declare the namespace like namespace MyProject.MyN1 { } and then try to rename it, the intelli-sense only looks at "MyProject" as the namespace, MyN1 is peripheral. But I'm really trying to rename "MyN1" and it doesn't like doing that.
Well, I tried that, and now I'm not sure what my problem was in the first place. As I described it it works fine. I think it was that if I try to add or remove a period in the namespace declaration it doesn't rename it right.
One way that would probably work is to using a global find and replace. What your actually trying to do is to rename two namespaces into one, and it's not going to let you.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Should Usings be inside or outside the namespace
sa1200 All using directives must be placed inside the namespace (StyleCop)
Is this just for code readibility or is there any actual advantage to doing so?
Does it help the GC somehow?
It definitely won't help with GC.
Here's the discussion about two styles:
https://learn.microsoft.com/en-us/archive/blogs/abhinaba/stylistic-differences-in-using
https://learn.microsoft.com/en-us/archive/blogs/abhinaba/do-namespace-using-directives-affect-assembly-loading
If you have multiple namespaces in your project, you can limit which namespaces are used by each one individually.
This might come in handy if there were class names in two different namespaces that were the same. One might be the default in one part of your project, while the other could be the default in another.
Yes they look for some really fringe cases for these rules.
There is no runtime difference. It's purely a compile time (and development experience) change. The file, compiled IL will be identical in either case.