Best way to check if a string is empty

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