'using' best practices

  • Thread starter Thread starter xzzy
  • Start date Start date
X

xzzy

I was wondering why we have to have
using System.Data
using System.Configuration
using etc....

why are they not all lumped into one 'using'?

In other words, is there a best way to use project classes with 'using'
meaning

is it best to put them all in one folder = no performance hit for doing so
using MyProject.Classes;

or

is it best to put them in different folders to avoid a performance hit by
'using' all of them
using MyProject.Classes.This;
using MyProject.Classes.That;
using MyProject.Classes.Other;

Thank you
 
xzzy said:
I was wondering why we have to have
using System.Data
using System.Configuration
using etc....

why are they not all lumped into one 'using'?

In other words, is there a best way to use project classes with 'using'
meaning

is it best to put them all in one folder = no performance hit for doing so
using MyProject.Classes;

or

is it best to put them in different folders to avoid a performance hit by
'using' all of them
using MyProject.Classes.This;
using MyProject.Classes.That;
using MyProject.Classes.Other;

Thank you
Click to expand...

Using has no efffect on performance, it is strictly a compile time nicety.
 
There is no runtime performance penalty based on the number of "using"
directives. The reason to minimize the number of namespaces is not to
improve performance, but to reduce the possibility of name collisions.

For example, if you have a MyFunkyCollection in both
MyCompany.Collections and MyCompany.Collections.Specialized, and you
have a "using" directive for both of those namespaces, the compiler will
not know which MyFunkyCollection you intend unless you qualify it in the
code. So, paradoxically, while "using" directives are intended to
reduce typing of fully qualified names, beyond a certain point they can
actually force you to use more fully qualified names because you have
too broad a list of "using" directives in place.

An example of this in the .NET framework itself is the fact that many UI
controls have the same names for both WinForms and ASP.NET applications
(for example, TextBox). This isn't a practical problem because you
would never actually reference both namespaces in the same application;
that wouldn't make sense. In general, namespaces are organized in such
a way that you would use them in combinations that wouldn't create
ambiguities. However, sometimes namespaces can evolve same-named
classes despite your best intentions, so there's no point in risking an
"ambiguous reference" compiler error by routinely stacking up 30 "using"
directives just in case you ever need anything in those namespaces.

Also, you need to be aware that a given "using" directive is not
inclusive of any levels that might exist beneath it. For example:

using MyProject.Classes

.... would not search MyProject.Classes.This when resolving fully
qualified names. You *must* include them all separately, anyway, if you
want the compiler to find the names within all levels of the namespace
hierarchy.

--Bob
 
Back
Top