Once when I was refactoring my code, I went up the IDE to the using section of my C# class, and cleaned unused namespaces and duplicate namespaces, and sorted them all.

My pair (pair programming) asked me the reason. I had no idea why I did that. I did it out of my habit to keep all of my code clean and tidy. I mean, I told him that having a cleaner code is a good idea in general, but of course that reason was not a good justification, as I won't even bother to spend my time in the using section of any C# code page.

Since many times you move a class or an enum (or a type in general) from one namespace to another namespace, and this adds new using statements to your code (either manually by going up the code window and writing the using statement yourself, or through the editor using Alt+Ctrl+F10 combination), and since these new using statements would be added to the end of using section, which makes them not sorted alphabetically, and since compiler never complaints about any of these problems, why should we care to make this section clean and tidy? What reasons might we have?


5 Answers 5


There is no performance difference, no matter how many using directives you have.

But I think it makes sense to keep them clean for two reasons:

  1. If you look at the usings, you can see what dependencies does the file have. This can help you figure out what the type(s) in the file do. If you do this, having the usings in a specific order helps you see it faster.
  2. If you have too many usings, it may indicate that you have poor separation of concerns and that the type(s) in the file do too much.

Both of these aren't very important, so you shouldn't worry about it too much. But personally, I think it makes it worth keeping the usings clean.


My main reasons to clean up amongst the using statements are:

  • The more using statements the more possibility of naming conflicts which would mean you have to include parts of the namespace in the code to avoid ambiguity.
  • The IntelliSense is filtered based on all the assemblies in your using statements. Therefore if you clean it up from unnecessary statements you'll help yourself by helping with the accuracy of the IntelliSense.

On top of that I agree with the other answers in that it increases readability and makes it easier to get an idea of what the type(s) in the class do.

  • I don't understand why this isn't higher voted. Namespace conflicts are a legitimate problem.
    – RubberDuck
    Oct 25, 2015 at 23:15

“Perfection is achieved not when there is nothing left to add, but when there is nothing left to take away” – Antoine de Saint-Exupery

Whenever you can remove something that is not necessary and does not add understanding, do so (readability is worth extra code).

  • Great aphorism. I liked the idea. +1 ;) Apr 24, 2012 at 3:41

It's just removing noise from the signal. Less noise means it's easier to receive the signal, i.e. understand the intent of the code.

As a generator of noise it's a pretty minor one though.

  • It improves readability of your code.
  • Normally it makes little sense to follow this guideline if you have just few using statements

  • It makes more sense to separate using statements into sections.

For example:

    using System.Web;

    using MyPlatform.FooX;        
    using MyPlatform.FooY;

    using MyFramework.Helpers;        
    using MyFramework.Extentions;

If I look at the class, then I can instantly see that given class is using System.Web assembly, as well as our platform and framework. This gives me a rough idea of its dependencies and complexity.

You can then take this a step further and order the statements, but I think that it makes using statements less readable, so I wouldn't recommend this.

using MyFramework.Extentions;
using MyFramework.Helpers;

using System.Web;

using MyPlatform.FooX;        
using MyPlatform.FooY;

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.