Best way to check if a string is empty

Hi all,

I am just wondering how you all check if a string is empty in C#.
I am a C/C++ programmer, and I usually check if the string is empty with the following code.

Code:

---

if( strString.length() == 0 || strString.compare( "" ) == 0 )
    // string is empty
else
    // do something useful with the string

---

so naturally, I am checking if a string is empty with the following code in c#

Code:

---

if( strString.length == 0 || strString.CompareTo( "" ) == 0 )
  // string is empty

---

Is there a better way to check if a string is empty in C#?
Thank you,
kab

Code:

---

if(String.IsNullOrEmpty(str))
{
//...
}

---

Assuming you do not need to differentiate between null and empty :D:D

If you want to check specifically for empty...

Code:

---

if (stringVar != String.Empty)
{
  //  It is NOT empty...however it might be Null.....
}

---

Ahh, I guess both functions are helpful, but I think IsNullOrEmpty is better for me =)
Thanks to both.

Hmm, TheCPUWizard, I can't give you another reputation. It seems like I have to wait for longer..

Quote:

---

Originally Posted by kabilius

Code:

---

if( strString.length() == 0 || strString.compare( "" ) == 0 )

---

---

In what language would an empty string *not* compare with "" to give the value of '0'. Isn't that a redundant statement no matter what language you're in?

Quote:

---

Originally Posted by Mutant_Fruit

In what language would an empty string *not* compare with "" to give the value of '0'. Isn't that a redundant statement no matter what language you're in?

---

Hi Mutant_Fruit,

Are you saying strString.length() == 0 is equivalent to strString.compare( "" ) == 0?
Yeah, now that I take a closer look, I think they are equivalent....
I don't remember why I put these two statements together, maybe it was just a way to make me feel that I am performing plentful sanity checks.....

kab

Quote:

---

Originally Posted by kabilius

maybe it was just a way to make me feel that I am performing plentful sanity checks.....

---

Sanity checks are great, but only if they add value. In this case, it's redundant.

Quote:

---

Originally Posted by Arjay

Sanity checks are great, but only if they add value. In this case, it's redundant.

---

Yes sir, I understand. I was trying to find a way out to explain why I have this redundant statement, and making me feel safer about my code was the best reason I found.... =p

Thanks for the input, I will try not to write statements like this in the future
kab

I do it like this, I added the Trim method just to eliminate spaces.

Code:

---

if (strString.Trim().Length == 0)

---

that's just one of those things that would get noticed and discussed during a code review. and why code reviews are such a worth while endeavor.

Quote:

---

Originally Posted by dee-u

I do it like this, I added the Trim method just to eliminate spaces.

Code:

---

if (strString.Trim().Length == 0)

---

---

I would not recommend doing that in any code that someone else has to modify. For one, it is inefficient (you are calling two methods instead of comparing against a static value), two, it is not clear why you would do that, and three, it is incorrect. however unlikely it may be, a string containing only spaces is not an empty string. You are not checking the value of the original string, you are creating a new string and checking its value.

Quote:

---

Originally Posted by BigEd781

I would not recommend doing that in any code that someone else has to modify. For one, it is inefficient (you are calling two methods instead of comparing against a static value), two, it is not clear why you would do that, and three, it is incorrect. however unlikely it may be, a string containing only spaces is not an empty string. You are not checking the value of the original string, you are creating a new string and checking its value.

---

Agreed. I try to avoid situations where extra leading or trailing spaces are added or when they are added, they're a necessary part of the string.

If I don't need the spaces, I'll trim them before I store them into the string.

That way any subsequent checks are reduced to

Code:

---

if( !String.IsNullOrEmpty( str ) )
{
  //...
}

---

Quote:

---

Originally Posted by BigEd781

I would not recommend doing that in any code that someone else has to modify. For one, it is inefficient (you are calling two methods instead of comparing against a static value), two, it is not clear why you would do that, and three, it is incorrect. however unlikely it may be, a string containing only spaces is not an empty string. You are not checking the value of the original string, you are creating a new string and checking its value.

---

Not only that, it will CRASH on a null string. :eek::eek:

TOTALLY DEFEATING the original purpose!

I'm glad to learn something which I was not aware of. Thanks guys!

Edit:
Actually, the primary reason I am using that is I am using this VB6.0 code to determine the 'emptiness' of a string and this is the most officient method I have known so far.

Code:

---

If Len(Trim$(x)) = 0 Then

---

All I thought it would convert to the .Net code I posted earlier.

Sorry for hijacking this thread but I just need a little more clarification.

For instance I have a Textbox that is used to input a Last Name that goes to a specific field in a table. A user pressed the Space key in the keyboard for that Textbox. If I need to store in a string the value of that textbox then how should I proceed?

If you always know that you want to have no spaces, you can call trim as soon as you save off the value:

Code:

---

string lastName = textbox.Text.Trim();
if (lastName != String.Empty)
{
    ...
}

---

You don't need to check for null here as you know the Text property of a textbox will never return null.

Quote:

---

Originally Posted by dee-u

Sorry for hijacking this thread but I just need a little more clarification.

For instance I have a Textbox that is used to input a Last Name that goes to a specific field in a table. A user pressed the Space key in the keyboard for that Textbox. If I need to store in a string the value of that textbox then how should I proceed?

---

In this case it is ok to do:
string s = textBox.Text.Trim();

Code:

---

if(String.IsNullOrEmpty(s)
{
 //use the value
}

---

since the text box cannot have a null text.

Though I would argue that it is better to just take away the spaces to begin with if you know they should not be there. This way you won't run into trouble down the road using that variable. At least this way you would not need to call Trim() twice.

determining whether the textbox is empty is one thing, validating input is another. Personally, I like to use an IExtenderProvider textbox validator that utilizes a regex to validate the input and can fire an event for invalid data. that way, validation can be added on a per-texbox basis in design mode, and all I have to do is handle a single event on the input validator extender for validation. combined w/ an error extender, its very simple.

its just much simplier than adding tons of code to check for null (since a textbox's text property will never be null), length, and content.

Quote:

---

Originally Posted by MadHatter

determining whether the textbox is empty is one thing, validating input is another. Personally, I like to use an IExtenderProvider textbox validator that utilizes a regex to validate the input and can fire an event for invalid data. that way, validation can be added on a per-texbox basis in design mode, and all I have to do is handle a single event on the input validator extender for validation. combined w/ an error extender, its very simple.

its just much simplier than adding tons of code to check for null (since a textbox's text property will never be null), length, and content.

---

100% agreement. Input validation should be done with Validators whenever possible, and should NOT be part of the "normal" processing code. The latter makes it too easy to miss something, obsures the real purpose of the code, and introduces many more opportunities for inconsistancy.

I'm sure you've all heard of the database tenet of garbage in/garbage out or, in other words, only store valid data into the database.

If we apply this concept to variables, then you'll only want to store valid data inside variables.

If you are getting external data (like from parsing a file for example), trim/validate the data before storing it.

If you get data from a textbox do the same before storing it (like using validators as suggested).

If you follow this style of programming, once a valid string is entered into a variable, then only the most basic check needs to be performed using String.IsNullOrEmpty(...).

As a final comment, I would still use IsNullOrEmpty(...) after validating text from a textbox even though the textbox text can't ever be null. Why? because it makes the code simpler and more consistent.

No matter how you code to check if a given string is a null string or not, the compare function is always called. Since the text length is 0 the execution takes O(1) time-complexity. Many not-so-oftenly-used functions to check for null string might include several other code which may be optimized away by the compiler, which might not be advised to use for internal structure branching conditions might be involved.

Quote:

---

Originally Posted by Khiem

No matter how you code to check if a given string is a null string or not, the compare function is always called. Since the text length is 0 the execution takes O(1) time-complexity. Many not-so-oftenly-used functions to check for null string might include several other code which may be optimized away by the compiler, which might not be advised to use for internal structure branching conditions might be involved.

---

That may be true nor C++ type strings (e.g. null terminated, std::string, etc) but is NOT ture for .NET's System.String - just look at the source code!

Disregarding null values of a string I'd think using the Length is still the fastest so I'd say it is best. If anyone could improve the benchmark that I did then pls. clarify.

With Trim:

Code:

---

private void button1_Click(object sender, EventArgs e)
        {
            Stopwatch stopWatch = new Stopwatch();

            string s = " ";
            string result = string.Empty;

            stopWatch.Reset();
            stopWatch.Start();
            for (int a = 1; a <= 10000; a++)
            {
                s = " ";
                Console.WriteLine(s.Trim().Length == 0);
            }
            stopWatch.Stop();
            result =stopWatch.ElapsedMilliseconds.ToString() + " = Using Length";
           
            stopWatch.Reset();
            stopWatch.Start();
            for (int a = 1; a <= 10000; a++)
            {
                s = " ";
                Console.WriteLine(String.IsNullOrEmpty(s.Trim()));
            }
            stopWatch.Stop();
            result += Environment.NewLine + stopWatch.ElapsedMilliseconds.ToString() + " = Using IsNullOrEmpty";
           
            stopWatch.Reset();
            stopWatch.Start();
            for (int a = 1; a <= 10000; a++)
            {
                s = " ";
                Console.WriteLine(s.Trim() == string.Empty);
            }
            stopWatch.Stop();
            result += Environment.NewLine + stopWatch.ElapsedMilliseconds.ToString() + " = Using string.Empty";
            MessageBox.Show(result);

            stopWatch = null;
        }

---

Without Trim:

Code:

---

private void button2_Click(object sender, EventArgs e)
        {
            Stopwatch stopWatch = new Stopwatch();

            string s = string.Empty;
            string result = string.Empty;

            stopWatch.Reset();
            stopWatch.Start();
            for (int a = 1; a <= 10000; a++)
            {
                Console.WriteLine(s.Length == 0);
            }
            stopWatch.Stop();
            result = stopWatch.ElapsedMilliseconds.ToString() + " = Using Length";

            stopWatch.Reset();
            stopWatch.Start();
            for (int a = 1; a <= 10000; a++)
            {
                Console.WriteLine(String.IsNullOrEmpty(s));
            }
            stopWatch.Stop();
            result += Environment.NewLine + stopWatch.ElapsedMilliseconds.ToString() + " = Using IsNullOrEmpty";

            stopWatch.Reset();
            stopWatch.Start();
            for (int a = 1; a <= 10000; a++)
            {
                Console.WriteLine(s == string.Empty);
            }
            stopWatch.Stop();
            result += Environment.NewLine + stopWatch.ElapsedMilliseconds.ToString() + " = Using string.Empty";
            MessageBox.Show(result);

            stopWatch = null;
        }

---

well first, you're using an unnecessary increment operation in your for loops (lest I digress... prefix increment is what you should be using).

second, the implementation of string.IsNullOrEmpty contains the following code:

Code:

---

public static bool IsNullOrEmpty(string value) {
    if (value != null) {
        return (value.Length == 0);
    }
    return true;
}

---

so the value != null instruction is pointless here since TextBox.Text is never going to be null, and it ends up using the string.Length property, so whether you use the text's length property, or string.IsNullOrEmpty, you're going to be accessing the string's Length property, so skipping one instruction will save you a tick.

having said that, looking at the implementation of TextBox.Text to see that its value will never be null could be considered a premature optimization by the purest because the Text property is never documented to always contain a value, so on that note, I'd probably opt for a string.IsNullOrEmpty, though I've seen lots of code written prior to .NET 2.0 that writes out the text != null && text.Length > 0 since that method wasn't available at the time the code was written. There is a lot to be said about consistency.

Quote:

---

Originally Posted by dee-u

Disregarding null values of a string I'd think using the Length is still the fastest so I'd say it is best. If anyone could improve the benchmark that I did then pls. clarify.

---

I don't think it really matters if it is faster or not. how often do you need to eek out performance from a check for an empty string? I go with readability first, performance...10th, once I am sure it is necessary. That's not to say that I knowingly write inefficient code, just that no one will notice a lost millisecond on a string compare, even if your benchmark is correct, which I doubt for String.Empty as it is a static constant.

Isn't .Length not readable enough?

well, it's not that bad, but I just prefer String.Empty or IsNullOrEmpty() as it is about as clear as possible. I'm not saying go and rewrite your code.

We should agree that it boils down to the personal inclination of a developer or organization, some would prefer performance over readability and readable for some can be not that readable to others, do you agree?

I find it hard to believe that:

Code:

---

if (str.Length == 0)

---

is appreciably faster than...

Code:

---

if (str == String.Empty)

---

...in almost every single situation. It is about three - four times as fast as far as I can tell, but unless you have a string compare in your video game's inner loop it probably will be meaningless.

...and the source for IsNullOrEmpty:

Code:

---

public static bool IsNullOrEmpty(string value)
{
    if (value != null)
    {
        return (value.Length == 0);
    }
    return true;
}

---

Exactly what you would have to do to protect against the crash pointed out by CPUWizard.

I can't agree that this type of optimization should win out over readability in 99% of the cases, but yeah, it's not a big deal and is not going to cause issues. Any programmer who doesn't get what str.Length == "" means should be fired anyway.

Quote:

---

Originally Posted by dee-u

We should agree that it boils down to the personal inclination of a developer or organization, some would prefer performance over readability and readable for some can be not that readable to others, do you agree?

---

Except that in either case, 'performance' doesn't come into it. It's another premature optimisation ;) If you're worried about performance differences between String.IsNullOrEmpty and string.Length == 0, you're worrying about completely the wrong things. What you should be worried about is whether or not you want to allow a null or empty string. If you don't, you should use String.IsNullOrEmpty.

Of course, the source of your string should be part of your 'view', which should be completely disconnected from your model and controller (MVC pattern), so your model will be doing all the validation, which means you can't rely on the source of your data being a TextBox, which means you can't rely on it being non-null.

Finally, near in mind that you validate before you store. Validation will done a hell of a lot less than the variable will be used, so even if you do 'mega optimise' your validation methods you're not going to get a real world performance boost.

I am not worried about the performance, its just that using .Length has its merits and should not be avoided like a plague, isn't it? And I am not worrying at all, it has become a second nature and to be honest I have not yet encountered a scenarion wherein a string has the value of null, I was not even aware of it until it has been mentioned in this thread.

Quote:

---

Originally Posted by dee-u

I am not worried about the performance, its just that using .Length has its merits and should not be avoided like a plague, isn't it?

---

I'd avoid it (or any other approach that uses a string instance method to determine whether the string is valid).

As I and others have mentioned earlier, you may consider validating the string data before storing it into the string variable. Then all your checks can be reduced to String.IsNullOrEmpty calls.

To illustrate, consider a situation where a string is valid if it contains alpha/numeric chars, no leading or trailing spaces, is not null and cannot start with a 'z' character.

If you validate (and/or trim) a string such as this prior to storing it into a variable, it just makes life easier.

Would you rather perform a validity check like this:

Code:

---

if( String.IsNullOrEmpty( str ) )
{
  //...
}

---

or

Code:

---

if( str != null && str.Trim( ).Length != 0 && str.Trim( )[ 0 ] != 'z' )
{
  //...
}

---

Hmmmnnn... That makes me wonder, if we need to pass something to a Business Logic Layer which is supposed to validate rules, are we supposed to validate them first in the GUI before sending them over to the BLL? I usually just do this in the GUI:

Code:

---

asset_bl.BLOCK_NO = textBLOCK_NO.Text;

---

and just let my BLL do the validation. Do you mean to say I need to validate the contents of textBLOCK_NO.Text first before setting them to asset_bl.BLOCK_NO?

It depends based on the type of feedback you wish to give your user.

If you validate in the UI, the user can get immediate feedback which is often quite nice.

Validating in the business object is good too; especially if the business object is accessed by something other than the UI.

So it seems maybe the logic should be in both places?

Well not really. Consider using the validation components in the enterprise library. These allow you to create validation attributes on the business object properties and then perform validation external to the business object. For UI's (like WinForms and WPF) this validation can be automatically connected so the user receives immediate feedback.

The validators can also be called on the business object level. With the entlib validator approach the validation logic is only in one spot but the validation can occur on different layers.

One last comment: You might consider following the C# .Net style guidelines/naming conventions. This will make your code easier to read for folks familiar with C#.

Quote:

---

Originally Posted by marceln

Code:

---

if(String.IsNullOrEmpty(str))
{
//...
}

---

---

It is only for C# 3. not earlier versions. At least not for Framework 1.1.

Quote:

---

Originally Posted by nabeelisnabeel

It is only for C# 3. not earlier versions. At least not for Framework 1.1.

---

It's available on .Net 2.0 and above. Hopefully no one is forced to code in 1.1 or earlier.

Pointing above mentioned point was necessary because we do not know in which framework version the topic starter is developing his application.

.NET version 1.1 is depricated, so I think we can safely assume that anyone posting here is using version 2.0 or higher. Going from 1.1 to 2.0 would not break anyone's code.

Quote:

---

Originally Posted by BigEd781

.NET version 1.1 is depricated, so I think we can safely assume that anyone posting here is using version 2.0 or higher. Going from 1.1 to 2.0 would not break anyone's code.

---

Correction:

.NET version 1.1 is in the process of depreciation, not depreciated yet.

Quote:

---

Originally Posted by nabeelisnabeel

Correction:

.NET version 1.1 is in the process of depreciation, not depreciated yet.

---

So..if you walked into a hotel with cracks in the walls and stained rugs, and no one had any intention of fixing it, would you say it was deprecated, or in the process of deprecation? In practice, it is an outdated API that no one should be using, but it is true that it has not yet been fully left behind in the dust (yet).

Quote:

---

Originally Posted by nabeelisnabeel

Correction:

.NET version 1.1 is in the process of depreciation, not depreciated yet.

---

Officially:

Quote:

---

Originally Posted by Microsoft Product LifeCycle

Retired .NET Framework 1.1 7/10/2003 -10/14/2008

---

Over two months past EOS

i think writing code base on .Net 1.1 is a horrible mistake because there are radical differences between 1.1 and 2.0; but not so many diffrence between 2 and 3.5