Why remove unused using directives in C#?

Question

I'm wondering if there are any reasons (apart from tidying up source code) why developers use the "Remove Unused Usings" feature in Visual Studio 2008?

Answer 1

Code compiles quicker.

Answer 2

There are a few reasons you'd want to take them out.

• It's pointless. They add no value.
• It's confusing. What is being used from that namespace?
• If you don't, then you'll gradually accumulate pointless using statements as your code changes over time.
• Static analysis is slower.
• Code compiles quicker.

On the other hand, there aren't many reasons to leave them in. I suppose you save yourself the effort of having to delete them. But if you're that lazy, you've got bigger problems!

Answer 3

I would say quite the contrary - it's extremely helpful to remove unneeded, unnecessary using statements.

Imagine you have to go back to your code in 3, 6, 9 months - or someone else has to take over your code and maintain it.

If you have a huge long laundry list of using statement that aren't really needed, looking at the code could be quite confusing. Why is that using in there, if nothing is used from that namespace??

I guess in terms of long-term maintainability in a professional environment, I'd strongly suggest to keep your code as clean as possible - and that includes dumping unnecessary stuff from it. Less clutter equals less confusion and thus higher maintainability.

Marc

Answer 4

Less options in the Intellisense popup (particularly if the namespaces contain lots of Extension methods).

Theoretically Intellisense should be faster too.

Answer 5

Ugh, surely to compile code quicker it's not enough to remove the reference from the file, but also from the project itself?

Answer 6

This seems to me to be a very sensible question, which is being treated in quite a flippant way by the people responding.

I'd say that any change to source code needs to be justified. These changes can have hidden costs, and the person posing the question wanted to be made aware of this. They didn't ask to be called "lazy", as one person inimated.

I have just started using Resharper, and it is starting to give warnings and style hints on the project I am responsible for. Amongst them is the removal of redundant using directive, but also redundant qualifiers, capitalisation and many more. My gut instinct is to tidy the code and resolve all hints, but my business head warns me against unjustified changes.

We use an automated build process, and therefore any change to our SVN repository would generate changes that we couldn't link to projects/bugs/issues, and would trigger automated builds and releases which delivered no functional change to previous versions.

If we look at the removal of redundant qualifiers, this could possibly cause confusion to developers as classes our Domain and Data layers are only differentiated by the qualifiers.

If I look at the proper use of capitalisation of anachronyms (i.e. ABCD -> Abcd) then I have to take into account that Resharper doesn't refactor any of the Xml files we use that reference class names.

So, following these hints is not as straight-forward as it appears, and should be treated with respect.