Using all

[lazyloader]

Instead of

using System;
using System.Collections.Generic;
using System.Threading;
using System.Collections;
using System.Threading.Tasks;
using Foo.A;
using Foo.B;
using Foo.ChildA;
using Foo.ChildB;
using Foo.C;
using ThirdPartyA.A;
using ThirdPartyB.Bar;
using ThirdPartyB.Bar.C;
using ThirdPartyC;
using ThirdPartyF.Baz;
using ThirdPartyF.Baz.A;
using ThirdPartyF.Baz.B;
...

We can just do:

using all;

And it all automatically include all possible namespaces. If there is a naming ambiguities, it will ask you to resolve them. For example, if both Foo.A and ThirdPartyA.A had a type Button, I could resolve the amiguity by doing something like this:

using all;

// not sure which one is better
not using ThirdParty.A;
!using ThirdParty.A;
-ThirdParty.A;
!ThirdParty.A;

The result is that code will be much easier to type and shorter. You could also go into settings to have namespaces implicitly removed from using all without having to type it, so if you rarely ever use System.Threading it won't be added, unless you did this:

using all;
using System.Threading;

[theunrepentantgeek]

The list of ALL possible namespaces is extremely large and would guarantee ambiguity - because some exist in the core framework libraries. It would likely also slow down compilation substantially. I'm already dealing with 13 minute compile times (yes, minutes) for full builds, so any slowdown is a non-starter for me.

There's a reason why the original language designers didn't do this.

[HaloFour]

You read code significantly more often than write code. It should be optimized for that purpose. Having to parse through a blacklist of namespaces would be significantly more complicated and confusing. And since namespaces bring in extensions as well as types the impact on code and resolving ambiguities would be a nightmare.

[AustinBryan]

The list of namespace you'd have to blacklist to resolve the ambiguities would no doubt be larger than the unrealistically large list you've used, thus defeating the point and making everything more confusing.

Besides that, !using Foo looks a lot like using Foo, which is what people have been using for almost 2 decades, and, if they're just skimming through or looking on only the right side, could looking like your including something that you're really excluding.

[jnm2]

I'd expect two things in practice: editor lag and conflicts which are irritating to resolve.

[bondsbw]

I've been tempted to propose the opposite, allowing you to import only specific types in a namespace instead of all. Several other languages take this approach.

The motivation would be to speed up compilation, though I don't have data to show how much of an improvement it would be. It would need to be significant for most developers to bother with the extra work of being explicit.

[HaloFour]

@bondsbw

I've been tempted to propose the opposite, allowing you to import only specific types in a namespace instead of all. Several other languages take this approach.

That might be where the Scala-like syntax would come in handy:

using System.Threading.Tasks.{Task, Task<T>}; // only import Task and nothing else

[bondsbw]

@HaloFour True.

[DavidArno]

Instead of

using System;
using System.Collections.Generic;
using System.Threading;
...

why not refactor your class to only have one responsibility, thus removing the need for gigantic using lists?

[igorocampos]

@lazyloader. you must think real hard to come up with these nice features!

[asyncawaitmvvm]

The list of ALL possible namespaces is extremely large and would guarantee ambiguity - because some exist in the core framework libraries. It would likely also slow down compilation substantially. I'm already dealing with 13 minute compile times (yes, minutes) for full builds, so any slowdown is a non-starter for me.

One thing people have to learn about Visual Studio is that the number of projects in your solution has a greater impact on build time than the size of the projects in your solution. Most teams have zero discipline isolating assemblies by functionality but isolate them anyway, meaning they're slowing the build down for absolutely nothing.

The result is that code will be much easier to type and shorter. You could also go into settings to have namespaces implicitly removed from using all without having to type it

Ctrl+.

Nobody has been actually typing out namespaces for years.

[jnm2]

Nobody has been actually typing out namespaces for years.

✋ Depends how well I know the API and which of the two things is easier to type.

[theunrepentantgeek]

@asyncawaitmvvm

One thing people have to learn about Visual Studio is that the number of projects in your solution has a greater impact on build time than the size of the projects in your solution.

As far as it goes, you're absolutely right about this - but your comment isn't relevant to my situation.

Excessive proliferation of projects isn't the reason the codebase I mentioned takes 13 minutes to build, even though there are around 400. My build times used to be 85 minutes, with the hard drive being the bottleneck. Since installing a (very fast) SSD as my development drive, build times dropped to around 13m, with the bottleneck now being the processor.

Compiler performance is important - and suggestions like this one, which would have a major impact on performance, worry me. I'm really appreciative of all the work the Roslyn compiler team has put into throughput and performance so far.

[theunrepentantgeek]

When I'm doing a code review, one of the things I do is to skim the list of using statements, to get a feel for what's going on with the code in that file.

The presence of cryptography related namespaces is informative; as are the namespaces for Windows.Forms, for WPF, for ASP.NET, for LINQ, for Immutable types, for testing frameworks (xUnit, Fluent Assertions), for utility libraries (moreLinq), and so on.

Sometimes the absence of a namespace is useful - if System.Collections.Generic is missing, for example.

Collapsing all that into an amorphous blob, by writing using all would be unfortunate.

[Nevynette]

I was just curious and wrote some code to count namespaces.

            var namespaces = AppDomain.CurrentDomain.GetAssemblies()
                .SelectMany(a => a.GetTypes())
                .Select(t => t.Namespace ?? "")
                .Distinct()
                .OrderBy(ns => ns)
                .ToList();

Simple Console App: 75
Simple WebApplication: 381