One thing I have noticed a lot of back and forth on is where using statements should be placed in a C# code file- whether its in the outermost scope or inside a namespace. I understand that the location of the using statement affects the scope of the references within that file, but what I don't understand is why, in most cases, someone would ever want their using statements inside their namespace.
In almost all cases only one namespace declaration ever exists in a single file so scoping the using statements seems/(is?) useless. If one were placing multiple types and multiple namespaces in the same file then scoped using statements make perfect sense, yet I still see plenty of cases of this being done even in files with one namespace. Why?
using System;
namespace MyNamespace
{
using System.Text;
public class MyClass {
// ...
}
}
An example of this being done throughout a project seemingly unnecessarily is the ASP.NET MVC source.
Putting "using" at the top of the files is the default way of Visual Studio. However, the recommended approach is putting the "using" statements inside of the namespace. Even MS's stylecop catches this and says the default way of VS is wrong.
Both techniques work fine.
StyleCop Rule says:
Placing multiple namespace elements
within a single file is generally a
bad idea, but if and when this is
done, it is a good idea to place all
using directives within each of the
namespace elements, rather than
globally at the top of the file. This
will scope the namespaces tightly, and
will also help to avoid the kind of
behavior described above.
It is important to note that when code
has been written with using directives
placed outside of the namespace, care
should be taken when moving these
directives within the namespace, to
ensure that this is not changing the
semantics of the code. As explained
above, placing using-alias directives
within the namespace element allows
the compiler to choose between
conflicting types in ways that will
not happen when the directives are
placed outside of the namespace.
Here's some links for further review:
Should 'using' statements be inside or outside the namespace?
Is sa1200 All using directives must be placed inside the namespace (StyleCop) purely cosmetic?
http://www.hanselman.com/blog/BackToBasicsDoNamespaceUsingDirectivesAffectAssemblyLoading.aspx
http://blogs.msdn.com/sourceanalysis/pages/sa1200-usingdirectivesmustbeplacedwithinnamespace.aspx
I'd never even seen/heard of this practice until I started using StyleCop and would get flagged by rule SA1200, which I now just disable. It's odd that the .cs files that Visual Studio creates as part of a new project violate this rule by placing the using directives at the very beginning of the file, outside of the namespace.
edited, with my head hanging in shame
Ahh! The using statement you're refering to is used to import a namespace, not to wrap an IDisposable object!
Very different, ambiguous terms... you had me confused :-)
Personally I like them outside the namespace at the top of the file; but it's probably due to me switching between C# and VB.NET.
I like to organize my projects into 1-file-per-class, no inner (nested) classes, and only one class per namespace (per file) . In this situation the location of the using statement is irrelevant whether inside or outside the namespace.
The iDesign C# coding standard is a solid standard to follow (or to derive your own from). It recommends keeping the using statements outside the namespace as item #14. But it's all down to your company / project's convention
Related
Sorry if this question was asked already.
I started studying C# and noticed that C# doesn't automatically import nested namespaces.
I don't understand:
using System;
should automatically import all classes contained in the System namespace right?
So there should be no need for me to write
using System.Windows.Form;
I would understand if using Windows.Form even worked. But the compiler could not resolve it! What is the point of the using System; before it then?
So why does using System; not import System.Windows automatically as well as System.Windows.Forms - sorry if the word import is wrong here.. maybe move to global namespace is the right terminology.
C# is not Java.
A using directive is used so you don't have to type in the fully qualified name of a type. It also helps with disambiguating type names (using aliases for instance).
In the case of Console, for example, you don't need to type System.Console.
It is important to understand the difference between a namespace and an assembly - a namespace is a logical grouping of types. An assembly is a physical grouping of types. Namespaces can span assemblies.
When you reference an assembly (this is more like importing a package in Java), you gain access to all of the public types in it. In order to use a type you need to uniquely identify it. This is done through the namespace - the using directive simply means you don't have to type the fully qualified name of the type.
The using directive has two uses:
To allow the use of types in a namespace so that you do not have to
qualify the use of a type in that namespace:
using System.Text;
To create an alias for a namespace or a type. This
is called a using alias directive.
using Project = PC.MyCompany.Project;
http://msdn.microsoft.com/en-us/library/sf0df423.aspx
However, you have to note that System and System.Windows.Form are not connected through name itself in anyway. If you import (using) System that means you will use the System assembly types in this class. Actual reference you specify in references section in Visual Studio project which you can really use (even without using statement, as this is just a shortcut for types).
C# doesn't import nested namespaces and this is by design.
Namespace scope lets you organize code and gives you a way to create
globally unique types.
Nested namespaces are used to group related functionality, but use parts of it on-demand.
I guess you wouldn't want to have all the types from such a big namespace like System if the only thing you need is System.Windows.
So probably the question is why C# doesn't have something like using System.*; like java does. I don't know the answer, but I guess this is because of KISS principle. It's something like using
select *
you will never know what types you will add and how they will affect existing code.
Even in Java you'd have to explicitly write
import System.*;
Much of the time you don't want all of the nested namespaces. These would simply clutter IntelliSense.
The "using" syntax allows you shorthand access to namespaces that are already listed as References in the project settings. If the namespace is listed as a reference you already have access to it by it's full name without the "using" directive. Just saves keystrokes.
"Using" a given namespace means that you will get access to all definitions implemented directly in it, not that it will recursively look up the embedded namespaces; doing otherwise would defeat the purpose of the "Using" statement.
Namespaces exist to avoid class name ambiguity. The "Using" statement is here to avoid the use of fully qualified types nested in namespaces, when you know no (or little) ambiguity may occur.
No, this is not how it works.
And I will give a good argument against what you said: intellisnse would go crazy and finding the what you want would be hell.
You do have access to everything on every namespace available (with dots), the using keyword simplifies this because you don't have to specify from which namespace a class or struct is "coming from" (I mean, defined).
Every time I creat a class, I see using System.Text that is added (amongst other using) by default. Every time I remove it after a while because it is unused according to ReSharper.
Am I missing a best practice? Do you use that namespace often? In which situation?
There has to be a reason why this namespace is referenced by default.
Thanks!
The System.Text namespace contains classes, abstract base classes and helper classes.
Say for example if you wanted to take advantage of the StringBuilder, Decoder, Encoder, etc....
The classes above, plays a significant role in most cases in .net. But it is not necessary for it to be there in your code. It only applies as to when you needed it. The important thing is to know when you will need the namespace.
It is added in visual studio by default for the convenience of the developers. Same with the
System.Linq namespace, not all of the time you will be using it but for your convenience it is already added assuming that you would be using it and that would be up to you to remove it which is by case to case basis.
Sometimes it would be a lot easier to delete it if it is not needed than to figure out the namespace and type when you need it :)
More info regarding System.Text
If it's not being used, it shouldn't be in the code. If Visual Studio adds them by default, chalk that up to Microsoft just trying to make things easy for a developer, as it thinks those are very common namespaces, but depending on what you are doing they likely aren't needed in many classes, just as you experience.
If you don't like it you can always create your own item templates. See http://msdn.microsoft.com/en-us/library/tsyyf0yh(v=VS.80).aspx
You should add using only for those namespaces that you really reference in the code.
This way the source file will not have a huge 'using header' and fewer namespace conflicts.
As you are using Resharper it is very easy to follow this rule.
If you are not using it, don't include the namespace. It is just automatically included because it is one of the more commonly used namespaces. I generally use it if I want to use regular expressions or string manipulation methods. But if you remove it and there are no compiler errors, it is safe to leave it out.
Almost all C# files have using statements at the top of the page
i.e.
using System;
using System.IO;
//code....
What do the using statements mean that are at the top of the page? Why is the syntax different from other using statement declarations.
i.e.
using (ResourceType resource = expression) statement
Those are using directives. They tell the compiler which namespaces to look in to find the classes you use in your code.
They look different (and are completely different) from the using statement which defines a scope for disposable objects.
These statements tellt he compiler which namespaces to look in to find the classes you are using in the code.
For example if you have
using System.IO;
Then your code to read all text of a file can be
File.ReadAllText("MyFile.txt");
rather than
System.IO.File.ReadAllText("MyFile.txt");
The using directive (as opposed to the using statement you mention that handles disposable objects) allow you to not specify the whole namespace of a class
i.e. if there is a class called
System.IO.FileStream
Then you could put
using System.IO;
And refer to it as
FileStream
(as long as the compiler can only determine a single thing that might mean)
using is a contextual keyword; it has more than one meaning, depending on how it's used.
At the head of a .cs file, it works like the java import instruction, specifying namespaces to search when looking for a type. If it's not listed, you must fully qualify types you use, which gets cumbersome. However, importing namespaes you don't need is wasteful and can introduce ambiguities.
Check out http://msdn.microsoft.com/en-ca/library/zhdeatwt(v=VS.80).aspx
The using keyword has two major uses:
As a directive, when it is used to
create an alias for a namespace or to
import types defined in other
namespaces. See using Directive.
As a statement, when it defines a
scope at the end of which an object
will be disposed. See using Statement.
1) The using keyword followed by a resource path provides a reference to a library in order to use additional/special classes and methods. This is similar to import-like keywords in other languages.
2) The using statement obtains the resource specified, executes the statements and disposes the object (releases from memory).
The kind of usings that exists are the
using directive, the one on top of files. It has two versions
using System.Text; - search this namespace for types that are not given by a fully qualified name. Similar to the %PATH% system variable.
using Project = PC.MyCompany.Project; - an "alias" for a type or namespace
The other kind of using is the using statement, the one with using (var foo = IDisposable){...}
This is a shortcut for a try-catch-block that calls Dispose on the foo-variable at the end.
Ok, I have a c# project named BusinessLayer which produces an assembly called BusinessLayer and the namespace is BusinessLayer.
Inside of this project, I am using folders to store code. One folder is called FilterElements and it has folders called FilterKeyReversal, FilterRandom and FilterToday.
Let's take the example of the FilterRandom folder. It has a class called LessThan10DaysGreaterThan50A with a namespace of BusinessLayer.FilterElements.FilterRandom and a single public static method called RunFilter();
In the code behind page of the website that is consuming this method, I have the using statement, Using BusinessLayer. I also have another using statement, using BusinessLayer.FilterElements.
I would think that to expose the RunFilter() method of the LessThan10DaysGreaterThan50A class, I could use the following syntax: FilterRandom.LessThan10DaysGreaterThan50A.RunFilter(), however I get the following error: The name FilterRandom does not exist in the current context.
If I use the following syntax inline, the error goes away: BusinessLayer.FilterElements.FilterRandom.LessThan10DaysGreaterThan50A.RunFilter(), or if I use a using statement of: Using BusinessLayer.FilterElements.FilterRandom, the following syntax works: LessThan10DaysGreaterThan50A.RunFilter().
I would rather use FilterRandom.LessThan10DaysGreaterThan50A.RunFilter() as it seems to make code more readable. If I use an alias with the following syntax of using FilterRandom = BusinessLayer.FilterElements.FilterRandom, I can get what I want, but don't really like the idea of using an alias since it can lead to confusion down the line.
I thought that since my BusinessLayer namespace has nested namespaces, I'd be able to pick up the remaining namespace, but I can't seem to get it to work. Anybody know how to make this work without using an alias, or am I going to have to use the entire namespace name every time?
Thanks.
Nope, it doesn't. I know it's very irritating.
My first try at solving this issue (I had the same issue) was adding these usings:
using FilterRandom = BusinessLayer.FilterElements.FilterRandom;
The problem then becomes that you have to add one for every sub namespace you want to include, and that becomes a mess.
How I permanently solved this is by changing the namespaces in the project so that, in your example, FilterRandom would e.g. be in BusinessLayer.
The problem you are actually seeing is that you have too many namespaces. It isn't strange it happens. They are a great way of organizing your code and classes and it's not that hard to have it go out of hand. What I mean by changing the namespaces is that I merged many small namespaces into larger ones. This sometimes means renaming classes, but my opinion is that the class name on itself should be meaningful, without the namespace prefix.
This way, I permanently solved these issues in my project (60kloc) and it worked out great.
Sometimes I've made a namespace in C# (I don't know if the problem is the same in VB.NET) containing 'System' and when I include it from a different DLL it goes crazy and conflicts with everything containing 'System'. This leads to crazy errors such as the following :
The type or namespace name
'ServiceModel' does not exist in the
namespace 'RR.System'
The type or namespace name 'Runtime'
does not exist in the namespace
'RR.System'
The type or namespace name
'SerializableAttribute' does not exist
in the namespace 'RR.System'
If you don't know what I'm talking about then good for you :) I'm sure many have seen this issue.
I'm not completely sure why it does this. It will occur even in files, such as generated code for web services that doesn't contain any reference to RR.System.
This all occurs just because I'm including RR.System the DLL in a different project.
How can I avoid this happening? Or fix it?
I still don't see why a child namespace conflicts with a root namespace? All types under a namespace can be fully qualified, and the fully qualified names refer to different types. e.g.
System.Abc.Xyz.Type
has nothing in relation to
Abc.Xyz.System.Type
The System in the first case refers to a completely different concept (The Company name under the guidelines), whereas the System in the second case could refer to the product or subsystem name.
If root namespaces can cause this kind of interference then surely that's a big problem because I may choose to call my new rainforest monitoring product Amazon and put all my types under MyCompany.Amazon. Then later on I may choose to store my data using the S3 storage and suddenly the namespace Amazon causes a conflict.
We've just run into the same issue as our project is split into 3 major sub-systems - Database, User and System. These seem like obvious child namespaces under our MyCompany root namespace.
Remember, this has nothing to do with Using statements as Simon said "It will occur even in files, such as generated code for web services that doesn't contain any reference to RR.System"
UPDATE: The following Stack Overflow question is along the same lines. However the MSDN article it points to discusses a class name called System hiding a namespace (fair enough) and also using System as a top-level namespace (fair enough). However it does not discuss why a child namespace conflicts with a root one.
Stack Overflow Q: Is global:: a bad code smell in C#?
MSDN Article: How to: Use the Namespace Alias Qualifier
Odd.
Now, why are you calling your project "System"?
To avoid confusion, you can fully qualify your namespace references:
global::System.ServiceModel
etc.
There isn't a way to reference both namespaces using the shorthand method. You'll either have to rename your class to prevent the collision, or alias your class like so (which will require you changing your references in your code to use the alias)...
Using System; // The namespace seen and used in all .cs files
Using Sys = RR.System; // Just replace -your- 'System' references with 'Sys'
While this method is legal in C#, it's messy and would suggest renaming your referenced class.
This reminded me of an old joke - Compiler, It hurts when I do this
If you have the option you may want to consider renaming your namespace to something like SystemUtilities or such, or you can just fully qualify all other references which can be a serious pain. Ambiguity with the BCL can lead to some nasty looking code.
If your project contains references to both System and your custom library (RR.System), the compiler will have an ambiguous reference to sort out. It's not sure which one you want.
You can always use aliasing to ensure that your code is explicitly referencing the correct code from your project.
BTW, there's a huge amount of best practice information to follow from Brad Abrams in Framework Design Guidelines.
The namespaces on my companies main projects are broken down to a few levels:
Company.au.ProductName.GUI.*
Company.au.ProductName.Data.*
...
where * would be further broken down depending on function
My company uses Company.Group.Platform.Application.Layer.Component.* It's very annoying and confusing. Needless to say, I use aliases