128

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?

raven
  • 18,004
  • 16
  • 81
  • 112
bounav
  • 4,886
  • 4
  • 28
  • 33
  • I believe that's a feature of PowerCommands for Visual Studio, not of Visual Studio itself. – Hosam Aly Mar 10 '09 at 11:11
  • 3
    In VS2008 it is certainly a feature (along with the ability to sort the using statements) of VS itself. – Richard Mar 10 '09 at 11:32
  • 1
    @Hosam: PowerCommands enables you to do that for the entire project/solution. Doing that per file is a feature of VS itself. – configurator Mar 13 '09 at 03:15
  • 3
    BTW, check out Resharper if you want more precise control over this kind of cleanup. – John Feminella Mar 14 '09 at 11:15
  • This is a dupe of http://stackoverflow.com/questions/136278/why-should-you-remove-unnecessary-c-using-directives – raven Jul 24 '09 at 17:04
  • 2
    I actually really dislike this feature -- I invariably find myself editing a file and having to re-add all the System namespaces after someone's cleaned them up (usually System, System.Collections.Generic, and System.Linq.) I find it adds more friction than it saves. Now, your own project namespaces rather than framework namespaces -- those make more sense to clean up, to clarify the wiring of your program. Wish there were a way to have VS clean up imports only from certain namespaces and leave the System ones that you more frequently need. – user1454265 Feb 12 '15 at 18:35
  • @user1454265 In the years since your comment, C# 10 has introduced Global Usings, which would allow you to add the common namespaces you mentioned to a single file, and let them be implicitly used in all other files. https://blog.jetbrains.com/dotnet/2021/11/18/global-usings-in-csharp-10/ – hypehuman Jun 20 '23 at 16:25

10 Answers10

200

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 compilation is slower.

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!

Neil
  • 7,227
  • 5
  • 42
  • 43
John Feminella
  • 303,634
  • 46
  • 339
  • 357
  • 66
    A good programmer IS lazy, he maximizes the work to NOT do. :D – Nicolas Dorier Apr 10 '09 at 12:36
  • CodeRush will allow you to move all the unused ones with a single mouseclick. – BenAlabaster Jul 24 '09 at 17:07
  • 40
    I don't agree that a good programmer is lazy, but I agree with the sentiment of your statement. A good programmer will delete them to keep his code clean and thereby avoid future work/problems/issues for himself and others. – Allan Aug 09 '11 at 17:11
  • 1
    @Allan this might help you understand the virtue of programmer laziness http://c2.com/cgi/wiki?LazinessImpatienceHubris – Matthew Lock Apr 19 '12 at 03:26
  • 2
    Right, that's a great link. I guess my point was just that we want "good lazy" rather than "bad lazy"; the latter being where programmers couldn't be bothered to write good code. – Allan Apr 27 '12 at 18:37
  • 6
    There is merit to leaving standard namespaces in as well. On large projects and teams, leaving them in results in fewer potential merge conflicts, and less files for code review. Additionally a lot of developers add confusing and hard to find extension methods to things, and sometimes locating the required namespaces for these extension methods is a hassle. New developers might be accustomed to having System.Linq, included in their code files, and waste a lot of time trying to figure out why certain methods aren't available before asking for help. – Mark At Ramp51 Sep 12 '14 at 09:50
  • 1
    Performance of compilation and static analysis can be solved with build time solutions via your build script, assuming you work in this type of setup. I don't know many programmers that evaluate the list of usings before just digging into the code. I'm not convinced the usings statements says all that much about the code, unless you work in an environment where it's a hard and fast rule that everyone cleans thier list of usings. Since most places aren't I don't think most people have this habit of making inferences about the code based on usings. – Mark At Ramp51 Sep 12 '14 at 09:52
  • 6
    You might wanna keep some of them to prevent the intellisense from being dumb as hell in future coding. – yazanpro Oct 18 '14 at 05:42
  • 2
    In my experience removing using System; using System.Collections.Generic; using System.Linq; (using System.Text;) is worse than have them unused. It is stressful write "DateTime" or StringBuilder or .Where (or many other things) and lose time to read errors like: _"The type or namespace 'DateTime' is not resolved..."._ Or _"The type or namespace 'Exception' is not resolved..."_. Or errors like _"XXX does not contains a definition for 'FirstOrDefault' and no extension method 'FirstOrDefault' accepting the first argument accepting X bla bla bla "_. – Alex 75 Apr 06 '16 at 22:32
26

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

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
18

In addition to the reasons already given, it prevents unnecessary naming conflicts. Consider this file:

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

This code doesn't compile because both the namespaces System.IO and System.Windows.Shapes each contain a class called Path. We could fix it by using the full class path,

        private static string temporaryPath = System.IO.Path.GetTempFileName();

or we could simply remove the line using System.Windows.Shapes;.

hypehuman
  • 1,290
  • 2
  • 18
  • 37
16

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 in 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.

Pang
  • 9,564
  • 146
  • 81
  • 122
  • 7
    Good Point, but you should not also forget that mantaining clean uncomplicated code enhances maintainability which is also a business objective. You have to weight both. Ideally you want to do these kind of refactorings just after a release so that you can have a as clean as possible slate to start a new and have plenty of time to catch eventual regressions. – David Reis Oct 21 '10 at 00:47
14

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

Theoretically IntelliSense should be faster too.

Pang
  • 9,564
  • 146
  • 81
  • 122
cbp
  • 25,252
  • 29
  • 125
  • 205
  • 1
    +1 for intellisense. It's actually slow on startup (I regularly see "Building cache, try again later"), so this might be actually significant. Compile time that everyone else talks about... i've yet to see numbers. – Luc Apr 05 '13 at 09:02
5

Remove them. Less code to look at and wonder about saves time and confusion. I wish more people would KEEP THINGS SIMPLE, NEAT and TIDY. It's like having dirty shirts and pants in your room. It's ugly and you have to wonder why it's there.

Tim Duncan
  • 51
  • 1
  • 1
4

Recently I got another reason why deleting unused imports is quite helpful and important.

Imagine you have two assemblies, where one references the other (for now let´s call the first one A and the referenced B). Now when you have code in A that depends on B everything is fine. However at some stage in your development-process you notice that you actually don´t need that code any more but you leave the using-statement where it was. Now you not only have a meaningless using-directive but also an assembly-reference to B which is not used anywhere but in the obsolete directive. This firstly increases the amount of time needed for compiling A, as B has to be loaded also.

So this is not only an issue on cleaner and easier to read code but also on maintaining assembly-references in production-code where not all of those referenced assemblies even exist.

Finally in our exapmle we had to ship B and A together, although B is not used anywhere in A but in the using-section. This will massively affect the runtime-performance of A when loading the assembly.

MakePeaceGreatAgain
  • 35,491
  • 6
  • 60
  • 111
4

Code compiles quicker.

Dead account
  • 19,587
  • 13
  • 52
  • 82
  • 5
    Got any evidence to back that up? – cjk Mar 10 '09 at 13:08
  • 16
    Oh CK - you caught me out again. I lied. Removing unnecessary text actually makes the code compile slower. Think about it :) – Dead account Mar 10 '09 at 16:25
  • 19
    It would be nice to see some real stats. If we are saving just a few milliseconds while compiling, then speed isn't a compelling argument. However, there are other reasons to remove unneeded using statements. – Greg Mar 31 '09 at 05:53
  • 3
    It's not about lying or not. Any sensible people would guess that less clutter means more efficiency. The "evidence" to back it up is to provide value to your response and support the argument that "faster" does not mean just a few ms, but actually an improved experience to faster compile your project. – Matheus Felipe Dec 29 '15 at 18:47
  • 1
    In fact I write short names for classes, variables and methods to have code that compile quicker. When I lose 1 minute to find that using System.Linq is missing when I try First/FirstDefault/Single/Single/FirstOrEmpty/SingleOrSomething/DefaultWhenNull... "WTF... I'm sure there is a method for this.. why I can't find it?" or "why Int32 doesn't compile today???" I think that 1 minute lost it worse than 1/1000 second earned in compilation. – Alex 75 Apr 06 '16 at 22:50
3

It also helps prevent false circular dependencies, assuming you are also able to remove some dll/project references from your project after removing the unused usings.

Jeremy C.
  • 74
  • 4
2

At least in theory, if you were given a C# .cs file (or any single program source code file), you should be able to look at the code and create an environment that simulates everything it needs. With some compiling/parsing technique, you may even create a tool to do it automatically. If this is done by you at least in mind, you can ensure you understand everything that code file says.

Now consider, if you were given a .cs file with 1000 using directives which only 10 was actually used. Whenever you look at a symbol that is newly introduced in the code that references the outside world, you will have to go through those 1000 lines to figure out what it is. This obviously slows down the above procedure. So if you can reduce them to 10, it will help!

In my opinion, the C# using directive is very very weak, since you cannot specify single generic symbol without genericity being lost, and you cannot use using alias directive to use extension methods. This is not the case in other languages like Java, Python and Haskell, in those languages you are able to specify (almost) exactly what you want from the outside world. But even then, I will suggest to use using alias whenever possible.

Pang
  • 9,564
  • 146
  • 81
  • 122
Earth Engine
  • 10,048
  • 5
  • 48
  • 78