 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / September 2007string.Empty
I have been told that it is a good idea to *always* declare string variables with a default value of string.Empty - for cases where an initial value is not known... like this: string myString = string.Empty; // do this string myString; // do not do this Questions 1. Is that a good rule? 2. If so, why? If not, why not? Thanks! > I have been told that it is a good idea to *always* declare string variables > with a default value of string.Empty - for cases where an initial value is [quoted text clipped - 5 lines] > Questions > 1. Is that a good rule? No. > 2. If so, why? If not, why not? Generally speaking, if a rule says "always" and it involves restricting you above and beyond what the language allows, it's not a good rule. In this particular case, I see no reason at all that initializing string variables with null is in appropriate in a variety of situations. Initializing with string.Empty (or the equivalent) is desirable when you want to always be able to assume the string is initialized to an instance, and an empty string is a useful value. But to say that doing do is _always_ the right thing to do is wrong. Pete Hi, >I have been told that it is a good idea to *always* declare string >variables with a default value of string.Empty - for cases where an initial >value is not known... like this: Not idea why you want to do that. > string myString = string.Empty; // do this > string myString; // do not do this You know that those two lines are not the same right? String is a reference type, that means that in the second line it will be unassigned (referencing null for lack of a better way of saying). The first line assign it to an instance. Now if you have a type where you want to use as a default String.Empty then it makes sense. But that is far from being *always* <"Ignacio Machin \( .NET/ C# MVP \)" <machin TA laceupsolutions.com>> wrote: > You know that those two lines are not the same right? String is a reference > type, that means that in the second line it will be unassigned (referencing > null for lack of a better way of saying). The variable being unassigned and the variable having an assigned value of null are very different things. If you do: string myString; for a *member* variable, the variable is assigned the value null. If you do it for a *local* variable, the variable isn't assigned at all - its value isn't null, it *has* no value yet, as far as the compiler is concerned.  SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > I have been told that it is a good idea to *always* declare string variables > with a default value of string.Empty - for cases where an initial value is [quoted text clipped - 5 lines] > Questions > 1. Is that a good rule? No rule that says you should *always* do something no matter what the situation is ever a good rule. All rules have exceptions. > 2. If so, why? If not, why not? I have seen, though not often, scenarios where it was important to know if the field was uninitialized or if it was set to a value of "". Following the above rule, that distinction would no longer be possible. SignatureTom Porterfield What's going on is that I'm trying to learn best practices and guidelines. Juval Lowy has published a document "C# Coding Standard - Guidelines and Best Practices" What it amounts to is a list of rules with no explanations. I wouldn't just blindly follow the rules - especially suspicious of any that start out with "[always | never ]do xyz". His rule #55 states "use string.Empty rather than"" So, yes - I botched the OP here because the rule talks about string.Empty vs. "" as opposed to string.empty vs null (which I put in the OP). Anyway I've heard this rule from Jesse Lilberty as well. So give that at least two well published authors speak of it, I wanted to understand the reasoning behind it. Thus the OP here. -S >> I have been told that it is a good idea to *always* declare string >> variables with a default value of string.Empty - for cases where an [quoted text clipped - 14 lines] > the field was uninitialized or if it was set to a value of "". Following > the above rule, that distinction would no longer be possible. > What's going on is that I'm trying to learn best practices and guidelines. > Juval Lowy has published a document "C# Coding Standard - Guidelines and [quoted text clipped - 3 lines] > blindly follow the rules - especially suspicious of any that start out with > "[always | never ]do xyz". Maybe it's just a pet peeve of mine or something, but I tend to avoid authors who tell the reader they *should* do something without providing any explanation as to why. For curiosity's sake though, maybe someone could mention what the practical difference is between: string s = string.Empty; and string s = ""; I am of course, assuming it's generally understood that a definition without assignment will be null. Chris. >> What's going on is that I'm trying to learn best practices and >> guidelines. Juval Lowy has published a document "C# Coding Standard - [quoted text clipped - 19 lines] > I am of course, assuming it's generally understood that a definition > without assignment will be null. As strings are interned, a reference to string.Empty would be the same as a reference to "", so I can't see that there is any difference from that standpoint. After that, it looks like just coding style to me. SignatureTom Porterfield Hi, >>> What's going on is that I'm trying to learn best practices and >>> guidelines. Juval Lowy has published a document "C# Coding Standard - [quoted text clipped - 23 lines] > a reference to "", so I can't see that there is any difference from that > standpoint. After that, it looks like just coding style to me. I agree, just a matter of style. Note that it can be make clear by looking to the code generated with both expressions. > > I am of course, assuming it's generally understood that a definition > > without assignment will be null. > > As strings are interned, a reference to string.Empty would be the same > as a reference to "", so I can't see that there is any difference from > that standpoint. After that, it looks like just coding style to me. Nope, string.Empty and "" won't be the same reference, at least they're not guaranteed to be. The code below prints False on my box: using System; public class Test { static void Main() { object x = ""; object y = string.Empty; Console.WriteLine (x==y); } } I wouldn't like to say why, given the IL for the static constructor of String, but there we go. Personally I prefer "" to string.Empty - I find it clearer. I've never seen any good reasons presented for using string.Empty instead. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too >> As strings are interned, a reference to string.Empty would be the same >> as a reference to "", so I can't see that there is any difference from [quoted text clipped - 14 lines] > } > } Yep, did a small test, though slightly different, and confirmed the same (see reply to Peter Duniho). > I wouldn't like to say why, given the IL for the static constructor of > String, but there we go. Hehe. I'll poke around in it when I get a chance. > Personally I prefer "" to string.Empty - I find it clearer. I've never > seen any good reasons presented for using string.Empty instead. SignatureTom Porterfield >> > I am of course, assuming it's generally understood that a definition >> > without assignment will be null. [quoted text clipped - 17 lines] > } > } True but.... string x = ""; string y = string.Empty; Console.WriteLine (x==y); will output true, "strings" are interned "objects" are not...... Willy. > > Nope, string.Empty and "" won't be the same reference, at least they're > > not guaranteed to be. The code below prints False on my box: [quoted text clipped - 18 lines] > > will output true, "strings" are interned "objects" are not...... Indeed - but the point of the exercise was to check for equal references, not equal objects. I think we can all agree that string.Empty and "" will always refer to equal strings. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > Indeed - but the point of the exercise was to check for equal > references, not equal objects. I think we can all agree that > string.Empty and "" will always refer to equal strings. Egad, I sure hope so. :-) SignatureTom Porterfield >> > Nope, string.Empty and "" won't be the same reference, at least they're >> > not guaranteed to be. The code below prints False on my box: [quoted text clipped - 22 lines] > references, not equal objects. I think we can all agree that > string.Empty and "" will always refer to equal strings. Yep, sorry my bad, did actually miss the other messages in this thread :-( Willy. >>> > I am of course, assuming it's generally understood that a definition >>> > without assignment will be null. [quoted text clipped - 25 lines] > > will output true, Of course it will. The value of the strings are equal. > "strings" are interned "objects" are not...... That's not why. The reason is that when you compare the strings, the value of the strings are compared, but when you compare the objects, the references are compared. If you do like this: object x = ""; object y = ""; Console.WriteLine(x == y); It will output true. As the strings are interned, the references that are stored in the variables are equal. SignatureGöran Andersson _____ http://www.guffa.com In addition to your point, The behavior changed from .NET 1.0/1.1 to 2.0. Under the old versions your test prints True. Have not tested under Orcas since I am redoing the vm. John >> > I am of course, assuming it's generally understood that a definition >> > without assignment will be null. [quoted text clipped - 23 lines] > Personally I prefer "" to string.Empty - I find it clearer. I've never > seen any good reasons presented for using string.Empty instead. With Orcas targeting framework 3.5 and 3.0 the result from that test is false. > In addition to your point, > [quoted text clipped - 31 lines] >> Personally I prefer "" to string.Empty - I find it clearer. I've never >> seen any good reasons presented for using string.Empty instead. Which test? SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com > With Orcas targeting framework 3.5 and 3.0 the result from that test is > false. [quoted text clipped - 34 lines] >>> Personally I prefer "" to string.Empty - I find it clearer. I've never >>> seen any good reasons presented for using string.Empty instead. The test in the message with message-id <u5AJNwV5HHA. 3728@TK2MSFTNGP06.phx.gbl>. > Which test? > > "Graeme Bradbury" <graeme.bradb...@bcs.org.uk> wrote in message > > With Orcas targeting framework 3.5 and 3.0 the result from that test is > > false. > [...] > So, yes - I botched the OP here because the rule talks about [quoted text clipped - 6 lines] > least two well published authors speak of it, I wanted to understand the > reasoning behind it. Thus the OP here. I discovered recently that in spite of string pooling, the literal "" and String.Empty are not equivalent. I didn't explore it any further to see if there was a way I could get "" and string.Empty to be pooled to the same string, but the default behavior didn't appear to. Since as far as I know, the string represented by string.Empty will always exist, you can avoid having a new empty string added to your string constant pool by always using that instead of "". However, I doubt there's much different beyond that. As long as string pooling is enabled, the worst that using "" instead of string.Empty should cause is: 1) the addition of a single extra string in the string constant pool 2) very slightly slower comparisons between one empty string and another when they aren't using the same version of the empty string (I'm assuming here that Equals() for strings checks for reference equality first, so if the constants are the same reference, this would shortcut the need to compare length and contents, speeding things very slightly). In other words, I can't imagine that there's any truly significant difference between the two. They aren't literally the same, at least in some situations, but you are unlikely to ever notice the difference in a real-world application. Pete > I discovered recently that in spite of string pooling, the literal "" > and String.Empty are not equivalent. I didn't explore it any further to > see if there was a way I could get "" and string.Empty to be pooled to > the same string, but the default behavior didn't appear to. Hmmm, this appears to be true. The following: string a = string.Empty; string b = ""; string c = string.Empty; string d = ""; Console.WriteLine(object.ReferenceEquals(a, b)); Console.WriteLine(object.ReferenceEquals(a, c)); Console.WriteLine(object.ReferenceEquals(b, d)); Yields the results: False True True > Since as far as I know, the string represented by string.Empty will > always exist, you can avoid having a new empty string added to your [quoted text clipped - 14 lines] > some situations, but you are unlikely to ever notice the difference in a > real-world application. Agreed. SignatureTom Porterfield Yes, that is a very different question. I would agree and I always use String.Empty rather than "" in this case. In theory at least, String.Empty is an existing string while "" is a new one. And so using String.Empty will result in one less string declaration (even if it contains no characters). That said, it's hard to always know what is going on internally within the compiler and libraries. It is not inconceivable that the compiler could automatically detect and then replace "" with String.Empty, although I do not recommend assuming that behavior. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com > What's going on is that I'm trying to learn best practices and guidelines. > Juval Lowy has published a document "C# Coding Standard - Guidelines and [quoted text clipped - 37 lines] >> if the field was uninitialized or if it was set to a value of "". >> Following the above rule, that distinction would no longer be possible. > Yes, that is a very different question. > > I would agree and I always use String.Empty rather than "" in this case. In > theory at least, String.Empty is an existing string while "" is a new one. "" is only new the very first time it's used in an assembly. > And so using String.Empty will result in one less string declaration (even > if it contains no characters). [quoted text clipped - 3 lines] > automatically detect and then replace "" with String.Empty, although I do > not recommend assuming that behavior. You can and *should* assume that string literals are interned, as it's part of the C# specification. It's not limited to empty strings. If you have the code: string x = "hello"; string y = "he"+"llo"; Console.WriteLine(object.ReferenceEquals(x,y)); then the spec guarantees that "True" will be printed out. Quite why it's not happening for string.Empty vs "" isn't clear at the moment, but in the general case it's fine. Now, the performance hit of introducing a single new string *once* is tiny - so what are the other benefits, if any, of using string.Empty instead of ""? It looks less clear to me... any of the string.Empty advocates like to make a case for it? SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Jon, > string x = "hello"; > string y = "he"+"llo"; > Console.WriteLine(object.ReferenceEquals(x,y)); > > then the spec guarantees that "True" will be printed out. Wow, sure enough. I didn't realize that. I wonder how much overhead is associated with that feature. For every value assigned to a String, it sounds like the libs looks up a list of all existing strings to see if there's a match. > Now, the performance hit of introducing a single new string *once* is > tiny - so what are the other benefits, if any, of using string.Empty > instead of ""? It looks less clear to me... any of the string.Empty > advocates like to make a case for it? As a long-time C/C++ and assembly language programmer, tiny performance hits are something I care about for the simple reason that you can end up with hundreds or even thousands of them in a substantial application. In fact, one thing that really bothers me about .NET is a lot of the extra overhead by many parts of how it is designed. That said, I'm not sure there would be any performance hit in this case given the information you gave above. I can imagine there could be some tiny bit of additional memory used. Other than that, it sounds like the library would simply look to see if "" is already a string and, if so, the string wouldn't be used any further. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com > > string x = "hello"; > > string y = "he"+"llo"; [quoted text clipped - 7 lines] > assigned to a String, it sounds like the libs looks up a list of all > existing strings to see if there's a match. No - only every string constant, and that only needs to be done once. The JIT compiler checks whether or not the string has already been interned when it compiles a ldstr instruction. In other words, there's very little overhead associated with it. > > Now, the performance hit of introducing a single new string *once* is > > tiny - so what are the other benefits, if any, of using string.Empty [quoted text clipped - 6 lines] > one thing that really bothers me about .NET is a lot of the extra overhead > by many parts of how it is designed. In this case, the overhead is one-off and really, really tiny. Even in C/C++ and assembly, the old adage about not micro-optimising until you know where there's a problem holds true. > That said, I'm not sure there would be any performance hit in this case > given the information you gave above. I can imagine there could be some tiny > bit of additional memory used. Other than that, it sounds like the library > would simply look to see if "" is already a string and, if so, the string > wouldn't be used any further. No - otherwise the examples we've looked at so far wouldn't have shown "" and string.Empty to be different references. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Jon, >> I wonder how much overhead is associated with that feature. For every >> value [quoted text clipped - 4 lines] > The JIT compiler checks whether or not the string has already been > interned when it compiles a ldstr instruction. So the point is you're saying it's compile time overhead. I didn't know "he" + "llo" was a constant but that's certainly something that a compiler could be made to figure out and handle. And, in fact, I see your examples returns False if I change it like this: string x = "hello"; string y = "he"; y += "llo"; MessageBox.Show(object.ReferenceEquals(x, y).ToString()); > Even in C/C++ and assembly, the old adage about not micro-optimising > until you know where there's a problem holds true. That's an issue for another discussion. >> That said, I'm not sure there would be any performance hit in this case >> given the information you gave above. I can imagine there could be some [quoted text clipped - 6 lines] > No - otherwise the examples we've looked at so far wouldn't have shown > "" and string.Empty to be different references. Well, that certainly would explain it, although there could potentially be other explanations. SignatureJonathan Wood SoftCircuits Programming http://www.softcircuits.com > > No - only every string constant, and that only needs to be done once. > > The JIT compiler checks whether or not the string has already been [quoted text clipped - 9 lines] > y += "llo"; > MessageBox.Show(object.ReferenceEquals(x, y).ToString()); It's partly a compile time overhead, figuring out the constant strings. There's a *slight* runtime overhead, as the JIT needs to check the intern pool at each ldstr instruction, but that only happens once (per instruction). <snip> SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too <snip> Not to wander too far off into the weeds here, but... RE: << The JIT compiler checks whether or not the string has already been interned when it compiles a ldstr instruction.>> What is meant by "interned" in the above sentence? I've seen "interned" used a couple of times in this thread. Thanks. > What is meant by "interned" in the above sentence? I've seen "interned" used > a couple of times in this thread. Huh? I thought everyone knew the answer. The string is "interned" when it's put to work with no pay. Oh. Wait, not that's not it. :) Seriously: it's essentially the same as a regular string pool as seen in other languages, except that you can add new strings to the pool at runtime. The basic idea being that if a given string appears multiple times in code, each instance of the string can be compiled as a reference to the single string instance in the "intern pool". That way, you don't wind up with multiple copies of the same string bloating the compiled executable. The compiler does this automatically. Pete Thanks for the explanation. Now, I'm off to the "intern pool". :-) >> What is meant by "interned" in the above sentence? I've seen "interned" >> used a couple of times in this thread. [quoted text clipped - 15 lines] > > Pete > Seriously: it's essentially the same as a regular string pool as seen in > other languages, except that you can add new strings to the pool at runtime. [quoted text clipped - 6 lines] > > Pete I seem to remember this is why it's a bad idea to lock on a string. So if class A has private string s = "Lock"; and class B has private string s2 = "Lock"; when class A locks s it also locks class B's s2. I think that's right anyway. > I seem to remember this is why it's a bad idea to lock on a string. Well, I suppose that's _one_ reason why it's a bad idea to lock on a string. I'd hardly suggest it's the only reason. :) > So if class A has private string s = "Lock"; > and class B has private string s2 = "Lock"; > > when class A locks s it also locks class B's s2. If the strings are both declared as literals like that yes, I'd agree. There are other ways to generate unique string instances though, so if you really wanted to lock on a string, you could. In that respect, I don't think the string class is all that unique; whatever you lock on, you need to make sure it's unique for best results. It's just that it's a bit trickier _in certain cases_ with the string class. > I think that's right anyway. Yes, I do too. :) Pete > so what are the other benefits, if any, of using string.Empty > instead of ""? It looks less clear to me... any of the string.Empty > advocates like to make a case for it? For me, the reason has always been that I (to quote Brendan Tompkins[1] "hate having quoted strings in code". Even if "" is a very special string literal, it is still a string literal, and if your code contains many string literals scattered about, it could get hard to debug, at least when these string literals are part of program logic and not just printouts or composite formatting patterns. string.Empty might mean to a prospective future toucher of your code that you expressly want the empty string, whereas "" could mean a string literal which just happens to be empty. Also, string.Empty is more consistent with the usage style for constants like Integer.MaxValue, Timeout.Infinite, etc. So I agree it's a coding style issue. 1: http://codebetter.com/blogs/brendan.tompkins/archive/2003/10/14/2585.aspx > > so what are the other benefits, if any, of using string.Empty > > instead of ""? It looks less clear to me... any of the string.Empty [quoted text clipped - 11 lines] > consistent with the usage style for constants like Integer.MaxValue, > Timeout.Infinite, etc. So I agree it's a coding style issue. The reason I use Integer.MaxValue etc is that it's clearer than the numeric equivalent - it's not obvious that the literal *is* Integer.MaxValue. It's very clear that an empty string is an empty string. As a counter-example, if there were an Integer.Zero constant, would you use that instead of the literal 0? I really don't buy the 'if I have "" in code then I might not really want an empty string' argument, I'm afraid. In both cases you'd only want to change it if you wanted a non-empty string. I'm slightly less anti-string-literals in general than most people though. If a string literal only appears once in the code, I'm often (though not always) happy to have it "inline" rather than as a constant. I'm not really trying to persuade anyone to *stop* using string.Empty, just to say that using "" is perfectly reasonable too :) SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > I really don't buy the 'if I have "" in code then I might not really > want an empty string' argument, I'm afraid. In both cases you'd only [quoted text clipped - 4 lines] > (though not always) happy to have it "inline" rather than as a > constant. I tend to agree. Assigning a string to "" signals a clear intent and probably offers a clearer understanding of what is meant than string.Empty (if not, this thread probably wouldn't exist). Most programmers will be immediately familiar with what this does: string s = ""; Whereas it will require making assumptions and/or researching exactly what this does: string s = string.Empty; > I'm not really trying to persuade anyone to *stop* using string.Empty, > just to say that using "" is perfectly reasonable too :) Am I correct in assuming that string.Empty will not contain a different value based on the current system codepage/character set/encoding/etc.? Chris. <snip> > > I'm not really trying to persuade anyone to *stop* using string.Empty, > > just to say that using "" is perfectly reasonable too :) > > Am I correct in assuming that string.Empty will not contain a different > value based on the current system codepage/character set/encoding/etc.? Indeed. It's always equal to "". Unless code is comparing the references produced, it doesn't matter (from an execution point of view) whether you use "" or string.Empty. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too > Now, the performance hit of introducing a single new string *once* is > tiny - so what are the other benefits, if any, of using string.Empty > instead of ""? It looks less clear to me... any of the string.Empty > advocates like to make a case for it? Here is one stab at it. It fits better with String.IsNullOrEmpty() - Michael Starberg > Here is one stab at it. > It fits better with String.IsNullOrEmpty() In what way? That method name is easily understandable even if you use "" because you still think of it as "an empty string" anyway. Jon >> Here is one stab at it. >> It fits better with String.IsNullOrEmpty() [quoted text clipped - 3 lines] > > Jon Sure. I actually think it is a trivial discussion. What I don't like is that string is sealed. For webdevelopment I'd like a SafeString that is never null. Now I am using a wrapper class for this with implicit cast operators, but it is uglier. - Michael Starberg > Sure. I actually think it is a trivial discussion. Pretty much, yes. > What I don't like is that string is sealed. Whereas I'd be worried about a string that *isn't* sealed. I know that string is sealed and immutable - therefore I can pass strings around safely, knowing that nothing can change them at all. > For webdevelopment I'd like a SafeString that is never null. I can't say I've ever found it much of a problem, to be honest. The ?? operator in C# 2 makes it easier, too. SignatureJon Skeet - <skeet@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.