Default string initialization: NULL or Empty?

Question

I have always initialized my strings to NULL, with the thinking that NULL means the absence of a value and "" or String.Empty is a valid value. I have seen more examples lately of code where String.Empty is considered the default value or represents no value. This strikes me as odd, with the newly added nullable types in c# it seems like we are taking strides backwards with strings by not using the NULL to represent 'No Value'.

What do you use as the default initializer and why?

Edit: Based on the answers I futher my further thoughts

1. Avoiding error handling If the value shouldn't be null, why did it get set to NULL in the first place? Perhaps it would be better to identify the error at the place where it occurs rather than cover it up through out the rest of your codebase?

2. Avoiding null checks If you are tired of doing null checks in code, wouldn't it be better to abstract the null checks? Perhaps wrap (or extend!) the string methods to make them NULL safe? What happens if you constantly use String.Empty and a null happens to work it's way into your system, do you start adding NULL checks anyways?

I can't help but return to the opinion that it is laziness. Any DBA would slap you nine ways to silly if you used '' instead of null in his\her database. I think the same principles apply in programming and there should be somebody to smack those upside the head who use String.Empty rather than NULL to represent no value.

Related Questions

• In C#, should I use string.Empty or String.Empty or “” ?
• What is the difference between String.Empty and “”
• Null or empty string to represent no data in table column?

Answer 1

Is it possible that this is an error avoidance technique (advisable or not..)? Since "" is still a string, you would be able to call string functions on it that would result in an exception if it was NULL?

Answer 2

It depends on the situation. In most cases I use String.Empty because I don't want to be doing null checks every time I attempt to use a string. It makes the code a lot simpler and you are less likely to introduce unwanted NullReferenceException crashes.

I only set the string to null when I need to know if it has been set or not and where an empty string is something valid to set it to. In practice, I find these situations rare.

Answer 3

I either set it to "" or null - I always check by using String.IsNullOrEmpty, so either is fine.

But the inner geek in me says I should set it to null before I have a proper value for it...

Answer 4

+1 for distinguishing between "empty" and NULL. I agree that "empty" should mean "valid, but blank" and "NULL" should mean "invalid."

So I'd answer your question like this:

empty when I want a valid default value that may or may not be changed, for example, a user's middle name.

NULL when it is an error if the ensuing code does not set the value explicitly.

Answer 5

According to MSDN:

By initializing strings with the Empty value instead of null, you can reduce the chances of a NullReferenceException occurring.

Always using IsNullOrEmpty() is good practice nevertheless.

Answer 6

It depends.

Do you need to be able to tell if the value is missing (is it possible for it to not be defined)?

Is the empty string a valid value for the usage of that string?

If you answered "yes" to both, then you'll want to use null. Otherwise you can't tell the difference between "no value" and "empty string".

If you don't need to know if there's no value then the empty string is probably safer, as it allows you to skip null checks wherever you use it.

Answer 7

This is actually a gaping hole in the C# language. There is no way to define a string that cannot be null. This causes problems as simple as the one you are describing, which forces programmers to make a decision they shouldn't have to make, since in many cases NULL and String.Empty mean the same thing. That, in turn, can later force other programmers to have to handle both NULL and String.Empty, which is annoying.

A bigger problem is that databases allow you to define fields that map to a C# string, but database fields can be defined as NOT NULL. So, there is no way to accurately represent, say, a varchar( 100 ) NOT NULL field in SQL Server using a C# type.

Other languages, such as Spec #, do allow this.

In my opinion, C#'s inability to define a string that doesn't allow null is just as bad as its previous inability to define an int that does allow null.

To completely answer your question: I always use empty string for default initialization because it is more similar to how database data types work. (Edit: This statement was very unclear. It should read "I use empty string for default initialization when NULL is a superfluous state, much in the same way I set up a database column as NOT NULL if NULL would be a superfluous state. Similarly, many of my DB columns are set up as NOT NULL, so when I bring those into a C# string, the string will be empty or have a value, but will never be NULL. In other words, I only initialize a string to NULL if null has a meaning that is distinct from the meaning of String.Empty, and I find that case to be less than common (but people here have given legitimate examples of this case).")

Answer 8

An empty string is a value (a piece of text which, incidentally, happens not to contain any letters). Null signifies no-value.

I initialize variables to null when I wish to indicate that they do not point to or contain actual values - when the intent is for no-value.

Answer 9

For most software that isn't actually string-processing software, program logic ought not to depend on the content of string variables. Whenever I see something like this in a program:

if (s == "value")

I get a bad feeling. Why is there a string literal in this method? What's setting s? Does it know that logic depends on the value of the string? Does it know that it has to be lower case to work? Should I be fixing this by changing it to use String.Compare? Should I be creating an Enum and parsing into it?

From this perspective, one gets to a philosophy of code that's pretty simple: you avoid examining a string's contents wherever possible. Comparing a string to String.Empty is really just a special case of comparing it to a literal: it's something to avoid doing unless you really have to.

Knowing this, I don't blink when I see something like this in our code base:

string msg = Validate(item);
if (msg != null)
{
   DisplayErrorMessage(msg);
   return;
}

I know that Validate would never return String.Empty, because we write better code than that.

Of course, the rest of the world doesn't work like this. When your program is dealing with user input, databases, files, and so on, you have to account for other philosophies. There, it's the job of your code to impose order on chaos. Part of that order is knowing when an empty string should mean String.Empty and when it should mean null.

(Just to make sure I wasn't talking out of my ass, I just searched our codebase for `String.IsNullOrEmpty'. All 54 occurrences of it are in methods that process user input, return values from Python scripts, examine values retrieved from external APIs, etc.)

Answer 10

Strings aren't value types, and never will be ;-)

Answer 11

I always initialise them as NULL.

I always use string.IsNullOrEmpty(someString) to check it's value.

Simple.

Answer 12

seems like this is a special case of the http://en.wikipedia.org/wiki/Null_Object_pattern

Answer 13

I always declare string with string.empty;

Answer 14

Why do you want your string to be initialized at all? You don't have to initialize a variable when you declare one, and IMO, you should only do so when the value you are assigning is valid in the context of the code block.

I see this a lot:

string name = null; // or String.Empty
if (condition)
{
  name = "foo";
}
else
{
  name = "bar";
}

return name;

Not initializing to null would be just as effective. Furthermore, most often you want a value to be assigned. By initializing to null, you can potentially miss code paths that don't assign a value. Like so:

string name = null; // or String.Empty
if (condition)
{
  name = "foo";
}
else if (othercondition)
{
  name = "bar";
}

return name; //returns null when condition and othercondition are false

When you don't initialize to null, the compiler will generate an error saying that not all code paths assign a value. Of course, this is a very simple example...

Matthijs