Home/ Questions/Q 94817
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T23:33:39+00:00

I’ve been using ReSharper for the past months and, advertising aside, I can’t see

  • 0

I’ve been using ReSharper for the past months and, advertising aside, I can’t see myself coding without it. Since I love living on the bleeding ‘What the hell just went wrong’ edge, I decided to try my luck w/ the latest ReSharper 4.5 nightly builds. It’s all nice.

However, I’ve noticed that the using directives grouping format has changed, and I wanted to know which is closer to the general standards:

[OLD]

#region Using directives using System.X; using System.Y; using System.Z; using System.A; #region namespace X { ... }

[NEW]

namespace X { #region Using directives using System.X; using System.Y; using System.Z; using System.A; #region ... }

Other than just lazy loading references, does it serve any special purpose? (Been reading Scott Hanselman’s take on this @ http://www.hanselman.com/blog/BackToBasicsDoNamespaceUsingDirectivesAffectAssemblyLoading.aspx)

Thanks;

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. As Scott proceeds to discover in his post, there is no runtime difference between these two cases. Therefore, it does not serve the purpose of lazy loading references.

    If you read the comments in Scott’s blog all the way to the end, you will also see that the developer who passed this rumor to Scott (Mike Brown) says that he had only heard of this and not tested it himself.

    That said, it is possible that where you put the using directives might make a difference by giving a compiler error if you set up an alias for a type inside a namespace, and you have another type with the same name defined in the namespace. But that’s no runtime difference of course.

    Finally, I believe that MS coding guidelines say to do it as ReSharper 4.5 does. But it’s silly to blindly follow this rule ‘because MS says so’, since

    1. It has been proved that it offers no benefit.
    2. Your team’s (or your) usual coding style may very well be different.
    • 0