Why should you remove unnecessary C# using directives?

Question

For example, I rarely need:

using System.Text;

but it's always there by default. I assume the application will use more memory if your code contains unnecessary using directives. But is there anything else I should be aware of?

Also, does it make any difference whatsoever if the same using directive is used in only one file vs. most/all files?

---

Edit: Note that this question is not about the unrelated concept called a using statement, designed to help one manage resources by ensuring that when an object goes out of scope, its IDisposable.Dispose method is called. See Uses of "using" in C#.

Quash

Answer 1

It won't change anything when your program runs. Everything that's needed is loaded on demand. So even if you have that using statement, unless you actually use a type in that namespace / assembly, the assembly that using statement is correlated to won't be loaded.

Mainly, it's just to clean up for personal preference.

Undertake

but it can affect compilation time and Intellisense/IDE responsiveness. – Selfcontained

Allthough you're right in saying that it doesn't matter once your program runs, the reasons Pop Catalin's mentions are valid. So it's not just personal preference. – Aquilar

Answer 2

There are few reasons for removing unused using(s)/namespaces, besides coding preference:

• removing the unused using clauses in a project, can make the compilation faster because the compiler has fewer namespaces to look-up types to resolve. (this is especially true for C# 3.0 because of extension methods, where the compiler must search all namespaces for extension methods for possible better matches, generic type inference and lambda expressions involving generic types)
• can potentially help to avoid name collision in future builds when new types are added to the unused namespaces that have the same name as some types in the used namespaces.
• will reduce the number of items in the editor auto completion list when coding, posibly leading to faster typing (in C# 3.0 this can also reduce the list of extension methods shown)

What removing the unused namespaces won't do:

• alter in any way the output of the compiler.
• alter in any way the execution of the compiled program (faster loading, or better performance).

The resulting assembly is the same with or without unused using(s) removed.

Pharmacopoeia

And as you modify files, you will end up adding more and more namespaces to the beginning of the files. So if you don't remove unused namespaces, when you open the file, all you see is a giant list of namespaces instead of actual implementation. – Georgetta

Regarding faster compilation: Unused using directives in .cs files can prevent you from removing some (otherwise unused) assembly references from your .csproj project. If you have a "solution" of many projects, unnecessary references between the projects will force the projects to be compiled in a specific order when in fact they are independent and can be compiled in parallel. So remove unused using directives before you check for unused project references in a multiple project solution. – Nauru

This is a great explanation - in the end it doesn't have much to do with performance but rather best practices. Thanks for explaining! – Jasonjasper

Answer 3

Code cleanliness is important.

One starts to get the feeling that the code may be unmaintained and on the browfield path when one sees superfluous usings. In essence, when I see some unused using statements, a little yellow flag goes up in the back of my brain telling me to "proceed with caution." And reading production code should never give you that feeling.

So clean up your usings. Don't be sloppy. Inspire confidence. Make your code pretty. Give another dev that warm-fuzzy feeling.

Goebbels

Now that's what I wanted to hear :-) I am used doing a Organize Usings -> Remove and Sort every now and then. BTW, to me the upper two options in Organize Usings are meaningless. I am talking about VS2013 btw. – Judges

Answer 4

There's no IL construct that corresponds to using. Thus, the using statements do not increase your application memory, as there is no code or data that is generated for it.

Using is used at compile time only for the purposes of resolving short type names to fully qualified type names. Thus, the only negative effect unnecessary using can have is slowing the compile time a little bit and taking a bit more memory during compilation. I wouldn't be worried about that though.

Thus, the only real negative effect of having using statements you don't need is on intellisense, as the list of potential matches for completion while you type increases.

Cacomistle

Answer 5

You may have name clashes if you call your classes like the (unused) classes in the namespace. In the case of System.Text, you'll have a problem if you define a class named "Encoder".

Anyways this is usually a minor problem, and detected by the compiler.

Naked

Answer 6

Your application will not use more memory. It's for the compiler to find classes you use in the code files. It really doesn't hurt beyond not being clean.

Settler

Answer 7

It’s personal preference mainly. I clean them up myself (ReSharper does a good job of telling me when there’s unneeded using statements).

One could say that it might decrease the time to compile, but with computer and compiler speeds these days, it just wouldn’t make any perceptible impact.

Uppercase

Answer 8

Leaving extra using directives is fine. There is a little value in removing them, but not much. For example, it makes my IntelliSense completion lists shorter, and therefore easier to navigate.

The compiled assemblies are not affected by extraneous using directives.

Sometimes I put them inside a #region, and leave it collapsed; this makes viewing the file a little cleaner. IMO, this is one of the few good uses of #region.

Brune

They can be collapsed without a region – Seeing

@abatishchev: Yes, that's true in VS2010. – Brune

"One of the few good uses of #region", so you mean using #region is bad in most ways? – Herriott

Yes, #region is a code smell. It says too much is going on in your class. – Brune

Answer 9

if you want to maintain your code clean, not used using statements should be removed from the file. the benefits appears very clear when you work in a collaborative team that need to understand your code, think all your code must be maintained, less code = less work, the benefits are long term.

Noeminoesis

Answer 10

The using statement just keeps you from qualifying the types you use. I personally like to clean them up. Really it depends on how a loc metric is used

Invest

Answer 11

They are just used as a shortcut. For example, you'd have to write: System.Int32 each time if you did not have a using System; on top.

Removing unused ones just makes your code look cleaner.

Erfurt

Answer 12

Having only the namespaces that you actually use allows you to keep your code documented.

You can easily find what parts of your code are calling one another by any search tool.

If you have unused namespaces this means nothing, when running a search.

I'm working on cleaning up namespaces now, because I'm constantly asked what parts of the application are accessing the same data one way or another.

I know which parts are accessing data each way due to the data access being separated by namespaces e.g. directly through a database and in-directly through a web service.

I can't think of a simpler way to do this all at once.

If you just want your code to be a black box (to the developers), then yes it doesn't matter. But if you need to maintain it over time it is valuable documentation like all other code.

Reimport

Answer 13

The 'using' statement does not affect performance as it is merely a helper in qualifying the names of your identifiers. So instead of having to type, System.IO.Path.Combine(...), you can simply type, Path.Combine(...) if you have using System.IO.

Snobbish

Answer 14

Do not forget that the compiler do a lot of work to optimize everything when building your project. Using that is used in a lot of place or 1 shouldn't do a different once compiled.

Bi