|
C++ but applied equally, if not more so to C#...
On a recent contract I added a
<br />
using MynameSpace.MyStuff <br />
to the header and proceeded to use my classes. I got a roasting for the using 'using'. Some nobby quote like "If god had meant for us to use 'using' he wouldn't have given us namespaces'. I can see how 'using' can stop the prevention of name collision, but it does help in the speed of development.
<br />
System.Drawing.Color myColor1 = System.Drawing.Color.Red;<br />
System.Drawing.Color myColor2 = System.Drawing.Color.Green;<br />
System.Drawing.Color myColor3 = System.Drawing.Color.Blue;<br />
or
<br />
using System.Drawing;<br />
<br />
Color myColor1 = Color.Red;<br />
Color myColor2 = Color.Green;<br />
Color myColor3 = Color.Blue;<br />
Does anybody have any tips / hints /preferences when 'using' is ok, and when to use fully qualified types. Do you use 'using' for the framework and fully qualified for your own? A mixture of both?
"More functions should disregard input values and just return 12. It would make life easier." - comment posted on WTF
"I haven't spoken to my wife now for 48 hours. I don't like to interrupt her.
|
|
|
|
|
I would use 'using' anywhere that I am going to use an object from that namespace more than once. Seriously, anyone who tells you otherwise is a moron. This isn't C++, where namespace std contains pretty much everything, .NET namespaces are much smaller.
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: Seriously, anyone who tells you otherwise is a moron
Good enough for me. Cheers
"More functions should disregard input values and just return 12. It would make life easier." - comment posted on WTF
"I haven't spoken to my wife now for 48 hours. I don't like to interrupt her.
|
|
|
|
|
Christian Graus wrote: This isn't C++, where namespace std contains pretty much everything, .NET namespaces are much smaller.
Yes, therefore figuring out what namespace some Widget is in without resorting to Visual Sudio is very difficult, a fully-qualified name avoids the problem.
|
|
|
|
|
No, it doesn't. Perhaps if you're using intellisense to *search* for something, and elect to have to search *again*, rather than turn it into a using statement. I rarely find that I have to look, I know where most things I use are.
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
Christian Graus wrote: I know where most things I use are
Oh, yes, you know where the things you use are, but I might not. And snippets posted on here rarely include the using directives.
In a team environment, or one with consultants coming and going, the standard should be to never use the using directive.
|
|
|
|
|
PIEBALDconsult wrote: In a team environment, or one with consultants coming and going, the standard should be to never use the using directive.
I would expect members of my team to figure out which namespace something is in fairly easy. Visual Studio 2005 makes it even easier because the smart tag will pop up asking if you want it to create the using statement or make it fully qualified.
And if they are a consultant then I would most definitely expect them to be able to figure these things out or I'll be telling them where the door is.
-- Always write code as if the maintenance programmer were an axe murderer who knows where you live.
Upcoming FREE developer events:
* Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o ...
* Reading: SQL Bits
My website
|
|
|
|
|
I should add. The only time it is acceptable to use the fully qualified name is when the compiler needs it because two classes with the same name, but different namespaces, are defined.
I realise that some of the code generated by the designer will insert fully qualified names, but I just leave that be because I don't touch that code.
-- Always write code as if the maintenance programmer were an axe murderer who knows where you live.
Upcoming FREE developer events:
* Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o ...
* Reading: SQL Bits
My website
|
|
|
|
|
Don't forget in that situation you can use: using LameString = SomeThirdParty.String;
|
|
|
|
|
Personally, I always use "using", even if I declare one instance from it & only use the fully resolved namespaces when disambiguating. Being roasted for doing otherwise is pretty stupid. I've been coding in c# since the heady early days of .net 1.0 in Jan 2001 and have never run into problems using "using", other than needing to use phrases like "using 'using'"  .
If god had meant for us to write pointlessly ugly code like System.Drawing.Color my color = System.Drawing.Color.Red, he would never have sent us IDEs.
n
|
|
|
|
|
Aren't you contradicting your self :-
Use using when you want to declare create only few instance of the variable
and
use using statement when you have to use it many times.
"More functions should disregard input values and just return 12. It would make life easier." - comment posted on WTF
"I haven't spoken to my wife now for 48 hours. I don't like to interrupt her.
|
|
|
|
|
Ahem, Visual Studio is clearly not from God.
And even if so, why then doesn't VS automagically add using directives as you type? Such that if I type System.Diagnostics.StackFrame it could remove the System.Diagnostics. and add using System.Diagnostics at the top.
|
|
|
|
|
PIEBALDconsult wrote: why then doesn't VS automagically add using directives as you type?
It pops up a smart tag and asks you what you want to do. There may be situations where you need the full name to disambiguate. It may not know which namespace to use if the class name is used in two separate namespaces, one of which you may not be interested in.
PIEBALDconsult wrote: Such that if I type System.Diagnostics.StackFrame it could remove the System.Diagnostics. and add using System.Diagnostics at the top.
Because it doesn't know if that's what you really want. You may be planning to use another class called StackFrame elsewhere in your code but from a different namespace.
-- Always write code as if the maintenance programmer were an axe murderer who knows where you live.
Upcoming FREE developer events:
* Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o ...
* Reading: SQL Bits
My website
|
|
|
|
|
Colin Angus Mackay wrote: Always write code as if the maintenance programmer were an axe murderer who knows where you live.
Indeed, so don't use the using directive.
|
|
|
|
|
PIEBALDconsult wrote: Indeed, so don't use the using directive.
You're like a record stuck in its groove.
-- Always write code as if the maintenance programmer were an axe murderer who knows where you live.
Upcoming FREE developer events:
* Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o ...
* Reading: SQL Bits
My website
|
|
|
|
|
I always use using because it makes it easier to read the code and better for printing out code. I find having the fully qualified route as too much typing even though it is pretty descriptive.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
If Microsoft didn't intend for us to use using, the templates in Visual Studio wouldn't contain a dozen of them.
I usually remove the using statements for namespaces that I don't use at all, but that's only because I don't want them there. A using statement doesn't add anything at all to the compiled code, so it doesn't hurt anything at all to have them there.
To always specify the complete namespace only makes the code harder to read. (It's also more to type, but that's not really a good argument, as the actual typing is a rather small part of the programming.)
---
single minded; short sighted; long gone;
|
|
|
|
|
sure, try removing the first line "#using System;" that will be interesting!
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
That's the first thing I do when VS creates a new file for me.
I've even made some effort to alter the templates to save myself from having to do that.
|
|
|
|
|
Hi,
I was under the impression things would not work at all without "using System;"
i.e. I thought the compiler would then be unable to map "int" to "System.Int32"
but clearly it can and does, without any "using System;"
Thanks for bringing that to my attention.
I have the habbit of removing usings I don't need, such as
System.Collections.Generic when I don't need any generic stuff.
but I use using statements all the time, and I tend to add a comment mentioning
the first Class that caused me to include the using statement.
For me the shorter form is the better one, for it improves readability.
But I can imagine situations where lots of namespaces would be required,
and then things could become hard to understand without full qualification.
The only such situation I encountered so far is about timers, having at least three
different classes called Timer in the Framework.
Greetings
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips:
- make Visual display line numbers: Tools/Options/TextEditor/...
- show exceptions with ToString() to see all information
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Luc Pattyn wrote: I have the habbit of removing usings I don't need
(That would be all of them.)
The using directive adds nothing to the language; it only enables the programmer to type less.
It's kinda like goto, except goto may actually be needed in some very rare cases. (Keeping in mind that C# needs goto to simulate fall-through in switch statements.)
|
|
|
|
|
The using directive is merely a crutch for inexperienced programmers (hence its use in templates and other pieces of bad code). The only time I use a using directive is to make an alias of a very long namespace (and then very rarely).
I very much dislike seeing a snippet of code (perhaps posted on here) that refers to some Widget, and I have no idea where that type of Widget came from.
Or someone answering a question by saying, "You should use a Widget." -- without saying where the blasted thing resides!
Always use a fully-qualified name and you'll never be misunderstood.
Were I in charge, the using directive would be the first against the wall.
|
|
|
|
|
PIEBALDconsult wrote: The using directive is merely a crutch for inexperienced programmers (hence its use in templates and other pieces of bad code).
That is utter crap!
PIEBALDconsult wrote: I very much dislike seeing a snippet of code (perhaps posted on here) that refers to some Widget, and I have no idea where that type of Widget came from.
Perhaps you might want to turn your gaze upon yourself. Perhaps you are the inexperienced one?
PIEBALDconsult wrote: Were I in charge, the using directive would be the first against the wall.
Just as well you are not. 
-- Always write code as if the maintenance programmer were an axe murderer who knows where you live.
Upcoming FREE developer events:
* Glasgow: Agile in the Enterprise Vs. ISVs, Mock Objects, SQL Server CLR Integration, Reporting Services, db4o ...
* Reading: SQL Bits
My website
|
|
|
|
|
Good code is readable code. Full qualified names are anything but readable.
If anything fully qualified names are the crutch for inexperienced programmers who don't know where things are, code by intellisense, aren't able to hit 'find' in the object browser, or don't have the skill to notice when a conflict occurs.
Programming environments are continually evolving to provide more and more abstraction, which helps us make sense of complex situations. Why anyone would want to make their code more complex and difficult to understand is beyond me.
Regardless, your refactoring tools (even the built in ones) make dealing with your usings a total no-brainer.
|
|
|
|
|
Mark Churchill wrote: Full qualified names are anything but readable.
Not at all, I know when I read "System.Windows.Forms.Button" that it means "System.Windows.Forms.Button", and I don't have to guess that some "Button" may or may not be some other type of "Button" whose actual heritage is concealed (well, that's too strong a word actually) in a line waaay the ffff up at the top of the file.
Don't think of fully-qualified names as being for you, think of them as for they who come after you.
A case in point:
In yesterday's "Friday Programming Quiz" there is a snippet of code that refers to, among other things, mshtml.IHTMLInputElement, that's a fully-qualified name, so even though I've never heard of such a beast, I had little trouble tracking it down. Had the poster not fully-qualified the name (he didn't include a using directive, remember) I would have had a more difficult time.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
