Aaaarg....use the namespace
-
That's not "style", but a "preference"; the difference is that one needs arguments, the other doesn't. People who prefer the long naming should try prefixing everything with "global::".
Bastard Programmer from Hell :suss:
Eddy Vluggen wrote:
prefixing everything with "global::".
I tried that, briefly.
-
Actually, it's less time. As the compiler already knows in what namespace the StringBuilder is, he doesn't need to search all the used namespaces... But this difference is imperceptible.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
Sentenryu wrote:
the compiler already knows in what namespace the StringBuilder is
How?
-
Personally, I always import, unless there is already something with the same name imported. But it's a matter of taste.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
Sentenryu wrote:
I always import
But that's not what the
usingdirective does. There is no "import" in C# -- the closest to that is references. -
Just a little reminder: This is the "Hall Of Shame" and not he "Hall Of Bugs". There is no good reason to clutter ones code with superflous repetitions of the namespace prefixing the StringBuilder, except maybe when there is another implementation of StringBuilder floating around. Just my two cents! :)
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
-
Sentenryu wrote:
I always import
But that's not what the
usingdirective does. There is no "import" in C# -- the closest to that is references. -
Sentenryu wrote:
the compiler already knows in what namespace the StringBuilder is
How?
-
You specified it when you wrote
System.Text.StringBuilder...I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
Ah, so perhaps you were agreeing with me. I see now that my statement was unclear and I have added clarification.
-
Ah, so perhaps you were agreeing with me. I see now that my statement was unclear and I have added clarification.
Yes yes, I really have bad time expressing this things on languages other than my own... (actually, even in my own language sometimes I've bad times trying to express my self... :( )
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
-
Eddy Vluggen wrote:
prefixing everything with "global::".
I tried that, briefly.
PIEBALDconsult wrote:
I tried that, briefly.
..a good idea, if you are paid per line written. It should feel comparably to explicitly stating that a member is "private", and prefixing everything possible with "this".
Bastard Programmer from Hell :suss:
-
Personally, I always import, unless there is already something with the same name imported. But it's a matter of taste.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
-
PIEBALDconsult wrote:
I tried that, briefly.
..a good idea, if you are paid per line written. It should feel comparably to explicitly stating that a member is "private", and prefixing everything possible with "this".
Bastard Programmer from Hell :suss:
Eddy Vluggen wrote:
explicitly stating that a member is "private",
Which everyone should do. There should be no default access modifiers.
Eddy Vluggen wrote:
prefixing everything possible with "this".
Which I also do. Just because. :cool:
-
Eddy Vluggen wrote:
explicitly stating that a member is "private",
Which everyone should do. There should be no default access modifiers.
Eddy Vluggen wrote:
prefixing everything possible with "this".
Which I also do. Just because. :cool:
PIEBALDconsult wrote:
Which everyone should do. There should be no default access modifiers.
Why?
PIEBALDconsult wrote:
Which I also do. Just because. :cool:
The amount of symbols that you use to convey an idea would best be kept to a minimum.
Bastard Programmer from Hell :suss:
-
PIEBALDconsult wrote:
Which everyone should do. There should be no default access modifiers.
Why?
PIEBALDconsult wrote:
Which I also do. Just because. :cool:
The amount of symbols that you use to convey an idea would best be kept to a minimum.
Bastard Programmer from Hell :suss:
No, you prefix the member if a class with
thisto prevent any ambiguity. The method or property on it's own only implies where it is. If I have this code:class Thingy {
private int majig = 27;void summit() { if (majig > 42) { // clever code } }}
And I copy the test to another method, all bad things could happen:
void nuThang() { // lots of code int majig = 69; // lots more code // copied: if (majig > 42) { // clever code } }oops.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
No, you prefix the member if a class with
thisto prevent any ambiguity. The method or property on it's own only implies where it is. If I have this code:class Thingy {
private int majig = 27;void summit() { if (majig > 42) { // clever code } }}
And I copy the test to another method, all bad things could happen:
void nuThang() { // lots of code int majig = 69; // lots more code // copied: if (majig > 42) { // clever code } }oops.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
Copy/paste is often an invitation not to check what you just pasted. Your example might be a nice example on why we introduced the DRY principle, but being this abstract, one can't be sure. But no, I'd not be bloating my code for the sake of "easy copies". If it's that re-usable, I'll take the time to make it a snippet. --edit;
Nagy Vilmos wrote:
No, you prefix the member if a class with
thisto prevent any ambiguity..the same kind of ambiguity that you have if you don't use the full name against a type, including it's namespace. Do you have global variables that clash with the names of the property/method that you're calling from the current object that you need to specify explicitly that you need the property/method from "this" object?
Bastard Programmer from Hell :suss:
-
No, you prefix the member if a class with
thisto prevent any ambiguity. The method or property on it's own only implies where it is. If I have this code:class Thingy {
private int majig = 27;void summit() { if (majig > 42) { // clever code } }}
And I copy the test to another method, all bad things could happen:
void nuThang() { // lots of code int majig = 69; // lots more code // copied: if (majig > 42) { // clever code } }oops.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
Nagy Vilmos wrote:
you prefix the member if a class with
thisto prevent any ambiguityCorrect.
-
I don't see the shame on this, this guy just like to write long names :|
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
Sentenryu wrote:
I don't see the shame on this, this guy just like to write long names :|
:doh: Huh? I don't, read my message again. I don't want the repetitions so I just mentioned the namespace at the top & replaced things.
thatraja
FREE Code Conversion VB6 ASP VB.NET C# ASP.NET C++ JAVA PHP DELPHI ColdFusion
HTML Marquee & its alternativesNobody remains a virgin, Life screws everyone :sigh:
-
I disagree, it's just code, the compiler doesn't care* and it's better to give the next developer too much information rather than too little. But could they have all shared one static instance? How often are these methods called? Are there threading issues? How big do the StringBuilders become? Can you estimate how big? If large, then pre-allocating enough memory or re-using existing instances can eliminate a lot of needless re-allocation. * However, I suspect that when you use the using directive** the compiler must have to spend some additional time looking them up. ** Qualification added for clarification.
There I mentioned
StringBuilderis just an example. I found many similar things like below.System.Diagnostics.Trace.Write
System.Diagnostics.Trace.WriteLine
System.Drawing.Color
System.Configuration.Configuration
System.IO.StreamWriter
System.IO.StreamReader
System.IO.FileInfo
System.IO.FileStream
System.IO.StringReader
System.IO.StringWriter
System.IO.TextReader
System.IO.TextWriter
System.Xml.XmlDocument
etc.,
....
...
..
.Why so much repetitions? After that some more 100s of replacements done. Namespace at top.
thatraja
FREE Code Conversion VB6 ASP VB.NET C# ASP.NET C++ JAVA PHP DELPHI ColdFusion
HTML Marquee & its alternativesNobody remains a virgin, Life screws everyone :sigh:
-
Sentenryu wrote:
I don't see the shame on this, this guy just like to write long names :|
:doh: Huh? I don't, read my message again. I don't want the repetitions so I just mentioned the namespace at the top & replaced things.
thatraja
FREE Code Conversion VB6 ASP VB.NET C# ASP.NET C++ JAVA PHP DELPHI ColdFusion
HTML Marquee & its alternativesNobody remains a virgin, Life screws everyone :sigh:
-
Sentenryu wrote:
But it's a matter of taste.
No, it's not. Bloating code is an offence. Three offences, you're out.
Bastard Programmer from Hell :suss:
-
But, some folk like to bloat their code. ;) ;) I agree, there is no good reason to do this, but it is not as bad as wacky, buggy code.
Just because the code works, it doesn't mean that it is good code.
CIDev wrote:
I agree, there is no good reason to do this, but it is not as bad as wacky, buggy code.
To quote one of the arguments why it is;
CIDev wrote:
Just because the code works, it doesn't mean that it is good code.
And that's easy to explain; the more symbols you need to convey an idea, the more chances that there's an error in the communication. The more symbols, the more fluff, the more bugs.
Bastard Programmer from Hell :suss: