Proposal: Multiple imports per using directive

[bondsbw]

Multiple namespace imports from a common base namespace are often used together:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Reflection;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Media;
using System.Xml;

This is a proposal to add a shorthand block syntax to the using directive in order to declare multiple imports at once:

using System;
using System.{Diagnostics, IO, Reflection, Text, Xml};

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

using System.Windows;
using System.Windows.{Controls, Input, Media};

Advantages

The cleaner syntax encourages grouping of similar namespaces together and reduces the line count. Both factors improve the ability to review the namespace import list.

Similar Proposal

#1421 provides a similar feature with similar syntax. But according to comments, its nesting capability and usage of this keyword were deemed confusing.

The syntax from my proposal is based on other comments on that post (#1421 (comment) and #1421 (comment)) which eliminate nesting and this. These changes were viewed favorably based on comment votes.

I believe that creating a new proposal for these differences is warranted so that they do not get lost under a proposal which received many down votes.

[iam3yal]

@bondsbw The general idea is nice but tbh I really find this using System.{Diagnostics, IO, Reflection, Text, Xml}; harder to read than the traditional way so I'd prefer something like this using System.Diagnostics, IO, Reflection, Text, Xml;

[iam3yal]

The issue with this kind of proposals is that if you have this many using statements:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Reflection;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Media;
using System.Xml;

Then it might be a hint you need to refactor and even then I'm not I'm sure it's worth it.

Just my 2c.

[bondsbw]

The braceless syntax is good too. (Might need to think about whether #218 and other proposals for using would cause any conflicts... none that I can think of at the moment.)

[bondsbw]

Similar code is more likely to use similar imports. More likely to see this after a good refactoring:

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Media;
using System.Xml;

than this:

using System;
using System.Collections.Generic;
using System.Reflection;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Controls;
using System.Xml;

So even though there are fewer imports, they would be the ones more likely to benefit from reduction.

[CyrusNajmabadi]

The cleaner syntax encourages grouping of similar namespaces together

This is just a restatement of the proposal. :)

and reduces the line count. Both factors improve the ability to review the namespace import list.

TBH, this just doesn't seem to be that useful/important.

[CyrusNajmabadi]

I mean, just looking at your example:

using System.{Diagnostics, IO, Reflection, Text, Xml};

These namespaces are wildly different. WHy does having them all in one line make thigns easier to review than just seeing:

using System.Diagnostics;
using System.IO;
using System.Reflection;
using System.Text;
using System.Xml;

In both cases i can see you're using 5 wildly different namespaces... how does that help me? How does consolidation make it any better?

--

Another issue is that i don't see how it helps me to know those 5 namespaces are used in one line... but then these two namespaces are called out in different line:

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

Why is IO/Xml/Diagnostics really important to see together... but seeing Collections.Generic is not...

Basically... i'm not actually seeing how this makes things any clearer when i'm going to read a PR.

[bondsbw]

This is just a restatement of the proposal. :)

What I meant was to contrast with

using System.Reflection;
using System.Text;
using System;
using System.Windows;
using System.Windows.Controls;
using MyStuff;
using MyStuff.CollectionsEx;
using Logger;
using System.Threading.Tasks;
using System.Windows.Input;
using TheirStuff.Net;
using System.Xml;
using System.Windows.Media;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;

[bondsbw]

Another issue is that i don't see how it helps me to know those 5 namespaces are used in one line... but then these two namespaces are called out in different line:

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

Why is IO/Xml/Diagnostics really important to see together... but seeing Collections.Generic is not...

That's fair. I considered adding something like this to the proposal:

using System.{ Collections.Generic, Threading.Tasks };

[tannergooding]

using System.Reflection;
using System.Text;
using System;
using System.Windows;
using System.Windows.Controls;
using MyStuff;
using MyStuff.CollectionsEx;
using Logger;
using System.Threading.Tasks;
using System.Windows.Input;
using TheirStuff.Net;
using System.Xml;
using System.Windows.Media;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;

This would be infinitely more readable if you ordered them appropriately:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;
using System.Reflection;
using System.Text;
using System.Threading.Tasks;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Media;
using System.Xml;
using Logger;
using MyStuff;
using MyStuff.CollectionsEx;
using TheirStuff.Net;

[iam3yal]

@bondsbw

using System.Reflection;
using System.Text;
using System;
using System.Windows;
using System.Windows.Controls;
using MyStuff;
using MyStuff.CollectionsEx;
using Logger;
using System.Threading.Tasks;
using System.Windows.Input;
using TheirStuff.Net;
using System.Xml;
using System.Windows.Media;
using System.Collections.Generic;
using System.Diagnostics;
using System.IO;

How common it is to have that many namespaces in a single file? and why aren't they sorted?

That's fair. I considered adding something like this to the proposal

Don't you think that it's simple enough?

[tannergooding]

How common it is to have that many namespaces in a single file

@eyalsk, it isn't that uncommon, especially when dealing with the UI stacks (XAML, WinForms, etc).

[iam3yal]

@tannergooding If you have that many namespaces trust me, you're doing it wrong.

[bondsbw]

Nah, I've seen that many times. It happens quite often.

[tannergooding]

If you have that many namespaces trust me, you're doing it wrong.

@eyalsk, no. It depends on your dependencies/etc. Even just going through Roslyn, there are plenty of files that have ~7 usings and quite a few that have over 12. Such as: http://source.roslyn.io/#Microsoft.VisualStudio.LanguageServices.Xaml/Implementation/XamlTextViewCreationListener.cs,20e58dc1b7876041

When you are building UI components that depend on other layers of the stack, it is quite easy to have imports jump up.

I still am not a favor of this proposal, as I think having the IDE add/sort usings for you is sufficient; but having over 10 usings is not terribly unusual.

[CyrusNajmabadi]

This would be infinitely more readable if you ordered them appropriately:

Agreed. And note that this is something the IDE will do for you automatically now if you just 'format document':

[whoisj]

I'm not sure importing all namespaces under some namespace is particularly helpful. (And I would think it could only hurt compiler performance.)

Oh for sure - just throwing out ideas (as mentioned in the post)

[Mteheran]

if you don't want to see the namespace's list, just put them in a region

 #region namespaces

    using System;
    using System.Linq;
    using System.Web.Http;  
    using System.Threading;
    using System.Threading.Tasks;

 #endregion

[tannergooding]

@Mteheran, that requires an IDE (which already lets you collapse sequential using statements).

[bondsbw]

@Mteheran

if you don't want to see the namespace's list

That's not the point of the proposal.

[CyrusNajmabadi]

One of hte points was: and reduces the line count. it's reduced about as much as possible when it's only one line :D

[Mteheran]

in that case, I propose this syntax:

using System[(Linq, Web, Xml)];
using System[(All)]; 

[CyrusNajmabadi]

As someone reading the code, how is that easier to understand than just having three separate imports? What does this do to benefit me as a consumer/maintainer of this code?

[bondsbw]

@CyrusNajmabadi Mostly the same argument as object and collection initializers. Grouping and DRY.

(This comment is about the original proposed syntax. Not @Mteheran's.)

[CyrusNajmabadi]

@CyrusNajmabadi Mostly the same argument as object and collection initializers. Grouping and DRY.

Those arguments don't hold those. With Obj/Collection initializers what i get is the ability to know that i've created an actual instance at runtime that is fully initialized to that state i've provided. This is especially valuable as previously that may have taken many statements, but i'm in a context that only allows an expression. i.e.:

Foo(new Whatever { X = 1, Y = 2 ... });

The same does not apply to namespace/imports. Imports do not represent an 'instance'. There is no situations where i'm hampered by the need to do multiple imports over having a single one that would represent hte 'complete entity'.

Those guys also let me express the idea of "i don't want anyone to be able to access this value until initialization is complete". With statement-oriented initialization, there is nothing blocking me from accidentally leaking/using the variable prior to finishing this up. With initializers, i can express that idea simply. Again, no such concept holds for namespaces/imports. They're simply a way to bring names into scope. There is no concept of "the names should not be in scope until i specify all the sub-namespaces i want to bring in", nor would there need to be :)

[bondsbw]

This is especially valuable as previously that may have taken many statements, but i'm in a context that only allows an expression. i.e.:

Ha, I knew someone would bring that up.

Initializers are often used in the context of direct assignment. They are a popular replacement for multiple assignment statements, regardless of their ability to be used in any expression context. I doubt it's all about preventing leakage.

I really do think there is a readability improvement with such blocks.

[iam3yal]

@asyncawaitmvvm Emphasis on the word might but more importantly emphasis on your attitude.

[DavidArno]

@asyncawaitmvvm,

Ha, if you dislike folk then take up ten lines in a new file for an enum, you'd really hate my code, as four lines is enough for me, and three of those are for the namespace block 🤣

[yaakov-h]

@asyncawaitmvvm

The number of using statements has no correlation to what the code is doing except to say that complicated things must draw from many domains.

... which often triggers CA1502.

I have yet to see a method that has low cyclomatic complexity whilst drawing from many domains, i.e. many usings.

[terrajobst]

@asyncawaitmvvm

I appreciate the passionate discussion but I don't appreciate your tone towards others in the community (one example, second example). This behavior is a violation of our code of conduct. If you keep doing this, we might have to block your account, which I really don't want to do. However, we need to ensure that we can have a productive discussion with our community and the technical aspects are challenging enough that we cannot tolerate abusive behavior.