Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C#4.0
Hi everyone!What is the difference between String.Empty and ""?
for example ,
 
string s1=String.Empty;
string s2="";
 
Posted 24-Sep-10 0:53am
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 3

The most fundamental difference is missing from all previous answers.
 
Look at the declaration of string.Empty;
 
public static readonly string Empty;
 
So, strictly speaking this is not a constant. This is a read-only field actually assigned to a constant.
In the sample you provide with your question, "" is an immediate constant, (created every time you place it in the code).
I compared the two for referential equivalence using object.ReferenceEquals -- they appeared to be the same, but nothing really guarantee that.
 
The difference between a constant and read-only field can sometimes be detected during run-time. In particular, this is a reason why string.Empty is not allowed in attribute constructor where an attribute is allowed -- unfortunately! (see Toli's Answer Difference between String.Empty and ""?[^]).
 
In nearly all other cases, using string.Empty is allowed and highly preferred.

I usually consider mixing any kind of immediate constants (by the way, see this) with code as unacceptable, but make exclusion for code samples and other ad-hoc works.
 
One advice tip for not using "" in comparisons: test static predicate string.IsNullOrEmpty(string).
 
Another advice would be using resources instead of constants, but this is not always practical/possible. In resources, empty strings can be allowed.
  Permalink  
v5
Comments
Espen Harlinn at 26-Feb-11 11:01am
   
Good effort, my 5
SAKryukov at 26-Feb-11 19:46pm
   
Thank you, Espen.
It's interesting that in some article-related thread I had to proof that "" works correctly (somebody tried to argue it would create more and more unique objects every time, by object.ReferencesEqual can really test that). Nevertheless, I strongly against "" as it is actually still an unwanted immediate constant, as any other.
--SA
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 4

Placing magic values in code is typically frowned upon, for a variety of reasons (some of which have already been explained). Though string.Empty seems like a slightly different beast (e.g., because you do not actually have the ability to modify the constant, which is one of the reasons for using constants).
 
Here is one practical difference: you can right click on "string.Empty" and do a "find all references" to find where empty strings are used in your code. You cannot do that with an empty string assigned using double quotes.
 
Also, if you are trying to remove magic values from your code, you might as well make use of this existing constant so that empty strings don't trip you up when searching through your code for quotes that should not be there (e.g., if you have a single class that holds all your strings, such as a resource file that gets translated into a class, you could search all other files to ensure they don't contain quotes).
  Permalink  
Comments
SAKryukov at 20-Dec-10 22:54pm
   
This is wise.
 
I usually do not tolerate any immediate string constants in code and confine any constant definitions to very few special files and static classes.
 
If I had to make exclusion for "", cleaning code would be much more difficult.
I never do this exclusion (event though string.Empty is not allowed when attribute is allowed), so I can, for example, simply perform the search for '"' (single quote) and exterminate offending code.
Abhinav S at 21-Dec-10 0:07am
   
Good answer.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

Adding to what ashokbusybee corectly said, there are instances when you must use "", for example:
[DefaultValue("")]
public string MyStringProperty
{
    // Accessors
}
Try to put string.Empty there!
  Permalink  
Comments
programmer4programming at 24-Sep-10 7:37am
   
Thanks.
SAKryukov at 20-Dec-10 18:55pm
   
Toli, you should have added: this is because string.Empty is readonly static field, where only constant is accepted.
SAKryukov at 20-Dec-10 19:19pm
   
Also, designers of attribute classes should always avoid this situation. For example, if there is one constructor accepting string where empty string is allowed, there must be yet another (parameter-less) constructor that set this string slot to empty (or null, whatever is appropriate).
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

string.empty handles memory efficently than string x="";
"" actually creates an object but string.empty does not.
 
Also, it is a best practise to avoid hardcoding like "";
  Permalink  
Comments
programmer4programming at 24-Sep-10 7:37am
   
Thanks
programmer4programming at 25-Sep-10 9:10am
   
Reason for my vote of 5
Automatic vote of 5 for accepting answer.
SAKryukov at 20-Dec-10 19:22pm
   
I'm absolutely agree with your note on hard-coding "", but not with efficiency: try to call object.ReferenceEquals to compare the two -- it will return "true". I'm not sure this is guaranteed.
 
In nearly all cases, string.Empty is highly preferable.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 5

please see the following link
 
http://msdn.microsoft.com/en-us/library/system.string.empty%28v=VS.80%29.aspx
  Permalink  
v2
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 6

See this discussion[^] or
this[^].
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 7

The difference between string.Empty and "" is very small. String.empty will not create any object while "" will create a new object in the memory for the checking. Hence string.empty is better in memory management.
  Permalink  

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 406
1 Marcin Kozub 225
2 Sergey Alexandrovich Kryukov 205
3 Raul Iloc 170
4 Maciej Los 164
0 OriginalGriff 8,289
1 Sergey Alexandrovich Kryukov 7,407
2 DamithSL 5,624
3 Maciej Los 4,989
4 Manas Bhardwaj 4,986


Advertise | Privacy | Mobile
Web04 | 2.8.1411023.1 | Last Updated 21 Dec 2011
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100