Do you "organize" your 'using' statements?

More and more I find myself "grouping" my using statements ("Imports" in VB.NET). For example, I now try and do Microsoft framework namespaces first, then namespaces for DLL's developed at my employer and finally third party namespaces. Something like this:

using System;
using System.IO;
using System.Data;

using <company>
using <company>.<module>

using <third-party>
using <third-party>.<module>

Not sure why I do this. If anything, it gives me a rough idea of the types of references in the project. Those "groups" usually belong to a specific set of assemblies.

Or maybe I'm just not getting enough sleep... :)

11 Comments

  • I always do this too, normally mine are..



    Microsoft

    Third Party

    Company

  • Heh - I also predominantly use regions in VB.NET now, and have my code organised like ..



    #Region &quot; Controls &quot;

    #Region &quot; Private Members &quot;

    #Region &quot; Private Methods &quot;

    #Region &quot; Event Handlers &quot;



    The regions are formatted much nicer in VB.NET too.



  • Absolutely. I use slighltly modified order: System (Microsoft) namespaces, employer namespaces, application/solution namespaces, third-party namespaces. Within each one of these, I alpha-sort (e.g. System.Data followed by System.IO). Doing it this way makes it much easier to scan through the namespaces, IMO

  • Absolutely. I use slighltly modified order: System (Microsoft) namespaces, employer namespaces, application/solution namespaces, third-party namespaces. Within each one of these, I alpha-sort (e.g. System.Data followed by System.IO). Doing it this way makes it much easier to scan through the namespaces, IMO

  • I usually do it as follows:



    using System;

    using System.Data;

    using System.IO;



    using &lt;third-party&gt;

    using &lt;third-party&gt;.&lt;module&gt;



    using &lt;company&gt;

    using &lt;company&gt;.&lt;module&gt;



    Notice that I use alphabetical ordering withing each group and I put the third party before the company.

  • We do the same split.

  • I like your style,and I also do it like this.

  • Same here, including the alpha-sorting. Never knew this was so common.



    I've gotta comment on Scott McCullogh though. I don't like it when people use regions to separately group private member variables, events ...



    I find that it makes the class much harder to maintain. Just adding a property to a class will make you open many regions.



    Statements that belong together, should be grouped together. Therefore, I typically use regions to group functionality within my class, not accessibility or types (members, methods, events).



    I'll give a typical example of how I group things:



    public class Customer : IBizObject

    {

    #region IBizObject implementation

    private Guid id;

    public Guid ID

    {

    get { return id; }

    }

    #endregion



    // I always keep the private member and the property together

    private string name;

    public string Name

    {

    get { return name; }

    set

    {

    name = value;

    OnNameChanged(EventArgs.Empty);

    }

    }



    // I keep events that deal specifically with the property close to the property

    protected virtual void OnNameChanged(EventArgs e)

    {

    if (NameChanged != null) NameChanged(this, e);

    }



    public event EventHandler NameChanged;



    // Any methods that are specific to Name

    public void MakeNameUpper()

    {

    Name = Name.ToUpper();

    }



    // Other properties go here

    }



    This way of working has the added benefit that, when I don't feel the need to use regions (which would mean all members are being used together), the class is usually well-factored and does only one job, and does it well.

  • I group them too. It otherwise looks so cluttered. But then again, I also group private member variables in different regions, properties in a region, event handlers in a separate section of the code (below the form init region) and all other code above the region, class constructors as the first methods in the class, then publics, then internals/protected then private methods.

  • I sure do, but they also have to be ordered alphabetically within each group. System.IO before System.Data - what are you thinking!? ;-)



    Anally retentive? Yeah, probably... you should see my CD collection.

  • I do a very similar thing in the namespace imports and I use my #region like this:



    #region Code that does XYZ



    //code here



    #endregion Code that does XYZ



    The label *after* the #endregion helps me when an expanded region is too long and I need to figure out where it finishes.



    In VB, similar effect can be achieved like this:



    #Region &quot;Code that does XYZ&quot;



    'code here



    #EndRegion 'Code that does XYZ

Comments have been disabled for this content.