Namespace Qualification a Smell?

  • Thread starter Thread starter carl.manaster
  • Start date Start date
C

carl.manaster

Hi, Group,

I know it says not to mess with the "code required for Designer
support" that the IDE generates when I work with things in the layout
editor, but I nevertheless find myself making changes along these
lines:

this.bMagnifier = new System.Windows.Forms.Button();
this.bMagnet.Anchor = ((System.Windows.Forms.AnchorStyles)
((System.Windows.Forms.AnchorStyles.Top |
System.Windows.Forms.AnchorStyles.Right)));
this.bMagnet.Location = new System.Drawing.Point(304, 176);

==>

bMagnifier = new Button();
bMagnet.Anchor = ((AnchorStyles)
((AnchorStyles.Top |
AnchorStyles.Right)));
bMagnet.Location = new Point(304, 176);

just so it's easier for me to read.

I realize that it's "safer" for the code generator to so precisely
qualify the items it refers to, and I'm not really quibbling about the
code it generates (maybe a topic for another post). But I'm starting
to consider such qualifications to be what XPers call a "smell" - an
indication that something is wrong about the code.

When I can strip off the qualification and everything still works fine,
that's great. But when - and this has happened in my own code, not
that built by the IDE - qualifications are _required_ for the code to
function properly, it is a clue to me that the function I'm writing
really belongs in another namespace, probably in a different class. Or
that my namespace map is somehow less than ideal - a class isn't where
it belongs, or has a bad name, etc.
In the immortal words of The Onion: What do you think?

Peace,
--Carl
 
Carl,

Personally, I think there is a reason why they say not to mess with the
designer generated code, because you can break it! In this case, I don't
think there is anything wrong with what the designer is doing. As a matter
of fact, it's doing the ^right^ thing. The reason you get fully qualified
names is that it can't guarantee that the proper using statements will be in
the file the code is placed in, so it can't make assumptions about using
shortened type names.

Also, wouldn't just editing things in the designer just be easier? I
mean, if you want to hand edit code, that's fine, but the designer is there
specifically to make it easier to do these things, and not wade through
stuff like this.

Finally, in VS.NET 2005, you will notice that designer generated code is
kept in a completely separate file, so there should be no reason why you
^ever^ have to touch the stuff (ok, maybe no is too absolute, but it's
pretty darn close).

Hope this helps.
 
When I can strip off the qualification and everything still works fine,
that's great. But when - and this has happened in my own code, not
that built by the IDE - qualifications are _required_ for the code to
function properly, it is a clue to me that the function I'm writing
really belongs in another namespace, probably in a different class. Or
that my namespace map is somehow less than ideal - a class isn't where
it belongs, or has a bad name, etc.
In the immortal words of The Onion: What do you think?
Click to expand...

When you have to qualify things, it suggests that either you've named a
class the same as one of the ones in a namespace you've "used" (i.e.
got a using directive for) or you've "used" two namespaces containing
the same short class names.

It's worth trying to avoid framework class names if possible, IMO - but
there are duplicates within the framework already, particularly between
WinForms and WebForms.
 
Thanks, Nicholas,

But I like to mess around with my code. Like, extract and consolidate
all the creation, parameter setting, and adding-to-components-list for
one button into its own procedure, then call (eg) InitializeButtonFoo()
from InitializeComponents(). Then notice the (profound) similiarities
between InitializeButtonFoo() and InitializeButtonBar() and extract
their common functionality into InitializeButton(which)...

Ultimately, then, I can create buttons in a nice, standard way, in
code, and if I want to make a change to all buttons (color, say) it's
just a one-line change.

Certainly sometimes I just leave the IDE-generated code alone, but
sometimes I want to make it my own. And my own doesn't have any more
namespace qualifications than it absolutely needs...

Peace,
--Carl
 
What do you think?

I think you'll be posting questions about why the IDE messed up your
precious code soon.

It says "do not modify the contents of this method with the code editor" for
a very good reason.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.
 
Hi, Bob,
I think you'll be posting questions about why the IDE messed up
your precious code soon.
Click to expand...

:-) Not gonna happen. (the questions, not the messing up).
Peace,
--Carl
 
I know it says not to mess with the "code required for
Designer support" that the IDE generates when I work
with things in the layout editor, but I nevertheless find
myself making changes along these lines:
[snipped examples of removing namespace prefixes]
just so it's easier for me to read.
Click to expand...

Why do you need to read the automatically generated layout code?
when [...] qualifications are _required_ for the code to
function properly, it is a clue to me that the function I'm
writing really belongs in another namespace, probably in
a different class.
Click to expand...

Hm. This has only happened to me once, when I had a Location class
(representing a geographical location with a postal address) and a
Windows form to allow the user to create and edit locations. There was
namespace confusion because of the Location struct used for
positioning controls in containers.

I don't think it was architecturally wrong of me to want to use both
kinds of Location in a single class (form). It struck me more as a
shortcoming of the English language. Perhaps you have a better example
than mine...?

P.
 
Hi, Paul,
Why do you need to read the automatically generated layout code?
Click to expand...

To abstract out common functionality, chiefly - but, well, just to
understand what's going on in my own program. To make it mine.
I don't think it was architecturally wrong of me to want to use both
kinds of Location in a single class (form). It struck me more as a
shortcoming of the English language. Perhaps you have a better
example than mine...?
Click to expand...

I have a specific example, but it's a general question; here's the
example if it helps.

I have an indirect subclass of System.Windows.Forms.Form, and I've
placed it in its own namespace ("Info") and called it "Form".
Duplicating (against Jon's advice) the library name. My rationale is
that, within the Info space, this is the only Form I want to refer to,
and any linguistic games I might play to get around that fact
("Info.InfoForm", "Info.Form_", "Info.SpecialForm", "Info.MyForm",
etc.) are - well, not pretty.

But an Info.Form's role is to peek at other forms and say something
about them, so I found myself iterating over the other
System.Windows.Forms.Form(s), and initially wound up with a typecast
bug as I tried to treat each of them as just Form(s), which of course
meant an inadvertent and erroneous typecast to an Info.Form. Which I
initially solved by adding the namespace qualification. But needing to
do that suggested to me that the code, in Info.Form, where I was
iterating over all Forms, actually belonged somewhere else. Or I
should have found another name for Info.Form, or something - a smell,
as I said in the initial post.

Peace,
--Carl
 
Back
Top