views:

502

answers:

9

I know VS2008 has the remove and sort function for cleaning up using directives, as does Resharper. Apart from your code being "clean" and removing the problem of referencing namespaces which might not exist in the future, what are the benefits of maintaining a "clean" list of using directives?

Less code? Faster compilation times?

+8  A: 

For me it's basically all about less noise (plus making Resharper happy!).

I would believe any improvement in compilation time would be minimal.

Lars A. Brekken
That's my thinking too.
Carl
Yeah, I just get rid of them to keep Resharper happy. :-)
Stewart Johnson
+2  A: 

For me, a clean list of using statements at the beginning can give a good understanding of the types to expect.

Gulzar
+1  A: 

I saw a decent gain in compile time a few years ago when I first installed ReSharper (on an 18 project solution). Since then its just been about keeping it clean.

cfeduke
+10  A: 

If you always only have the using directives that you need, and always have them appropriately sorted, then when you come to diff two versions of the code, you'll never see irrelevant changes.

Furthermore, if you have a neat set of using directives then anyone looking at the code to start with can get a rough idea of what's going to be used just by look at the using directives.

Jon Skeet
Not really. I totally ignore the using blocks at the top as so much noise.
Robert C. Barth
They're not noise if you know that every using directive there is being used. Even if you *do* regard them as noise, they can still give false positives on diffs if you don't keep them in check.
Jon Skeet
A: 

I can't speak to the benefits in compile time and performance, but there's a lower chance of namespace collisions if you have minimize your using declarations. This is especially important if you are using more than one third party library.

Michael Meadows
+3  A: 

There's no runtime impact. It's purely compile time. It potentially impacts the following:

  1. Less chance for Namespace collisions
  2. Less "noise" in the code file
  3. Very explicit about which namespaces and possible types to expect in the file
  4. Using the menu to remove unused and Sort means more consistency with using statements among the devs. Less chance of dumb checkins just to fix it up.
Haacked
+5  A: 
  1. Less noise.
  2. Clear expectation of what types are used ("My UI layer depends upon System.Net. Wow, why?")
  3. Cleaner references: if you have the minimal set of using statements, you can cleanup your references. Often I see developers just keep throwing references into their projects, but they never remove them when they're no longer needed. If you don't have anything that actually needs a reference (and a using statement counts), it becomes trivial to clean up your references. (Why would you want to do that? In large systems that have been decomposed into components it will streamline your build dependencies by eliminating the unused deps.)
Mike Post
A: 

I found a duplicate question, with more responses here:

http://stackoverflow.com/questions/87696/are-unused-using-directives-expensive

Feel free to close this, if you have the power. ;)

Carl
A: 

There is one compile-time difference: when you remove a reference, but still have a using directive in your code, then you get a compiler error. So having a clean list of using directives makes it a little bit easier to remove unused references.

Usually the compiler removes unused references, but I don't know if that works when a using is in the code.