Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm a bit of a neat freak and tend to keep my projects by cleaning references and usings in each class to keep only what's actually used.

What other argument could I make (besides calming my OCD nerve) of keeping to the essentials? I'm thinking mostly system references, any reference to custom work will bring its lot of backward compatibility issues. Is the release footprint bigger? Compile time longer?

share|improve this question
4  
Note that usings and references are not the same thing. Many of the answers fail to take that into account. –  phoog Dec 28 '11 at 1:45

4 Answers 4

up vote 10 down vote accepted

Intellisense will be a heck of a lot more useful to you if you keep using at a minimum, and that is a great advantage.

Other than that, I do not think there is any gain. So maybe the C# compiler will work faster by, say, 1%; so what.

share|improve this answer
1  
The cummulative value of that 1% is considerable... but fundamentally you'd expect the compiler to optimise any problem away. However I don't have a problem with simply being tidy –  Murph Dec 25 '11 at 22:46
    
C# IntelliSense has been a bit messy anyway since around 2005, when they started dumping absolutely everything into the list. –  Rei Miyasaka Dec 25 '11 at 23:09
    
@ReiMiyasaka so that you get IntelliSense for whatever you want and then do Ctrl+. to quick fix "Add namespace XYZ" –  kizzx2 Dec 26 '11 at 4:51
1  
@Murph: no matter how big the cumulative value of 1% ends up being, it will still be 1% of the cumulated total, so it will always be inconsequential. Also, the compiler cannot disregard any usings until it has figured out that they are in fact unnecessary, but it cannot figure that out unless it has compiled your entire source file first. As with project references, they are not discarded just because they do not appear to be used, because they might be used in a dynamic (not detectable at compile-time) way. –  Mike Nakis Dec 26 '11 at 9:25
1  
A bit late, but in my case we're creating an app for a very limited-resource device. Adding unnecessary references will impact the final application size. And well we will try to distribute the package and compete against other packages, a bigger package may make the user think twice about whether or not to download the app. –  hmadrigal Jul 9 '13 at 13:08

Since it is virtually trivial to accomplish this in Visual Studio (simple right click), why not do it?

This is consistent with Occam's Razor, it is just plain good engineering.

As to the consequences of not doing it, consider what happens if some other developer tries to open your project and it contains an (unused) reference to a library that he/she does not have on his/her computer. Now that poor developer needs to figure out why that unresolved reference exists and what to do about it.

If you prefer, consider it in terms of the golden rule. Would you want to take over development on a project that had lots of references to libraries that you did not have on your computer and that you had no idea why they are there?

share|improve this answer
    
+1, there is an add-in that can do this for the entire solution. This also reminded me of ClojureScript and Google Closure video where whole program optimization is important since a typical web page is about 1MB now. It is a good habit to have - to clean things that are not needed. –  Job Dec 25 '11 at 22:37

using statements are simply for the compiler to be able to fully reference classes, etc. Extra using statements will have no appreciable effect on compilation time.

Also, the runtime won't load a referenced assembly until it is actually needed, so again I don't believe there are any negative consequences of unneeded references.

If you use a tool like Reflector, finding and removing these unnecessary bits can be mostly automated, so I'd say it's wasteful to spend much time at all on these activities. For example, an hour or two of manually removing unneeded using statements more than pays for a Reflector license - and it comes with many other productivity enhancing features.

share|improve this answer
    
Cleaning using's is a built in feature of VS 2010 (I think 2008 too). And ReSharper can do the references too. But yeah, before I'd embark on any large scale cleanup, I'd look into using a tool to do this for me. –  MPelletier Dec 25 '11 at 22:42
    
+1 for clearly expressing the distinction between unused usings and unused references. The two are very different! –  phoog Dec 28 '11 at 1:43

In addition to the above, I guess it was not yet mentioned here that, each reference requires a component either within the .NET framework or an external DLL. If the reference is made to an external DLL, you will need to have that when (and where) your run the software.

Edit - As per valid comment by phoog below: The application would still run if the DLL is not used and is not required to be shipped with the application just because it was added to references. To take care of un-used references in the code, you may want to look at: Removing unused references.

share|improve this answer
1  
If the reference is unused, you will not need the DLL when and where you run the software. –  phoog Dec 28 '11 at 1:44
    
@phoog, thanks for your comment. At least in .NET VS2010, if you manually add a reference to the solution, the DLL is physically added to the bin folder even if you don't use it in the code. –  Emmad Kareem Dec 28 '11 at 6:29
1  
But, if you delete the DLL from the bin folder, or publish the application without the DLL, the application should still run. –  phoog Dec 28 '11 at 15:28
    
@phoog, you are correct, thanks for pointing this out. I will edit the post. –  Emmad Kareem Dec 28 '11 at 16:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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