We Should Eradicate the Empty String — Here's Why

Introduction

Did you ever wonder what's the difference between an empty string and null?

For example, what's the difference between:

email = ""

... and:

email = null

Do both statements mean the same or not?

What are the pros and cons of using an empty string vs using null?

Do we need both versions, or could we get rid of one to simplify things?

Let's see.

What's the Problem?

Before revealing the answers to the questions raised in the previous section, it's helpful to first investigate the infamous "test for empty and/or null?" problem, encountered in many popular programming languages (C-family languages, Java, JavaScript, Python, etc.). Chances are you have encountered this problem firsthand, in various situations.

Consider a service provider company that needs to send an important email to inform all customers about an upcoming change of conditions. Before sending the email, the staff wants to check the customers' email addresses, and ensure that each customer has an email address defined in the database.

Here's an excerpt of code that does the job, written in Java (the code would be similar in other languages):

for ( Customer customer : customers ) {
    String id = customer.getId();
    String email = customer.getEmail();
    if ( /* TODO: no email address defined */ ) {
        writeError ( id + ": no email" );
    } else {
        writeInfo ( id + ": " + email );
    }
}

The interesting part in this code is the if statement that checks if an email address exists for the customer.

Practice shows that different developers are likely to check for the absence of an email address in different ways. Let's look at six possible variations.

Developer A follows the prevalent advice that functions should never return null, but empty strings (and empty collections), in order to simplify code and avoid the dreaded null pointer error. Therefore he assumes that customer.getEmail() returns an empty string if there's no email address. The code looks like this:

if ( email.isEmpty() ) {
    writeError ( id + ": no email" );
} else {
    writeInfo ( id + ": " + email );
}

Developer B is a member of a growing tribe of developers who embrace null. Only null should be used to represent the absence of value, and therefore she assumes that customer.getEmail() returns null if there's no email address:

if ( email == null ) {
    writeError ( id + ": no email" );
} else {
    writeInfo ( id + ": " + email );
}

Developer C wants to be on the safe side and tests for null or an empty string:

if ( email == null || email.isEmpty() ) {
    writeError ( id + ": no email" );
} else {
    writeInfo ( id + ": " + email );
}

Developer D also wants to be on the safe side, but he's having a bad day and gets the code wrong:

if ( email.isEmpty() || email == null ) {
    writeError ( id + ": no email" );
} else {
    writeInfo ( id + ": " + email );
}

Developer E also gets it wrong — not because the order of the expressions is wrong, but because she uses the non-short-circuiting or operator | instead of its short-circuiting counterpart ||, which also means that a null pointer error is thrown if email points to null:

if ( email == null | email.isEmpty() ) {
    writeError ( id + ": no email" );
} else {
    writeInfo ( id + ": " + email );
}

Developer F is having a very bad day and forgets to check if there's an email address:

writeInfo ( id + ": " + email );

Note

If email points to null then the outcome of the above code is language-dependant.

• In Java, appending null to a string appends the string "null" — hence a message like C123: null is written.

• Other languages (e.g. C#) append nothing, which results in C123: .

• Some languages might throw an exception at run-time.

• The safest approach (in a null-safe language) is this one: the compiler generates an error, requiring us to decide what to do whenever we try to append a nullable value to a string.

Now let's see what happens at run-time.

Besides considering the above six code variations from the consumer side of customer.getEmail(), we also need to take into account the possible variations on the supplier side.

If there is no email address defined, then customer.getEmail() might:

• return null

• return an empty string

As there are six variations on the consumer side, and two on the supplier side, the (surprisingly high) number of combinations is: 6 x 2 = 12.

The following table shows the outcome for all combinations of supplier/consumer code. You don't need to scrutinize this table — you can just skim over it, because the goal of this example is to provide an idea of the complexity and error-proneness involved in this simple example.

Points of interest:

• The outcome is correct in 50% of the cases.

  There's a 25% chance for the worst outcome: a silently ignored error.

• Only the code of developer C, which checks for null, then for an empty string, and uses the right operator (||), works correctly in all cases.

• If the code on the supplier- or consumer-side is changed later on, then the outcome might change too. Code that worked correctly might become buggy, or vice versa.

• If customer.getEmail() sometimes returns null, and sometimes an empty string (depending on the value stored in the database), then the code might work correctly for some customers, but not for others.

Note

Some languages support additional values, besides null and empty strings. For example, Javascript also has undefined. VBScript has four values: Nothing, Empty, Null, and empty strings. When I wrote this article, I initially intended to provide an even more problematic example including undefined, along with null and an empty string. However, because of the exponential increase in combinations, I abandoned this idea swiftly.

The above example demonstrates what you probably knew already: Checking for null and an empty string is cumbersome and error-prone.

Wouldn't it be great if we could get rid of this recurring annoyance?

Testing for the absence of an email address should be straightforward, and there should be only one right way to do it, ideally enforced by the compiler.

Is There a Solution?

"Delete," he said. "Delete, delete, delete."

— Isaacson, Walter. Elon Musk, 2023, pp. 402

Because checking for both null and an empty string is a common pattern, C# provides a static String method named IsNullOrEmpty.

Instead of writing:

if ( email == null || email == "" )

... you can simply write:

if ( String.IsNullOrEmpty ( email ) )

Java doesn't provide such a method in its standard library, but some third-party libraries do. For example, Google Guava provides Strings.isNullOrEmpty(), and Apache Commons provides StringUtils.isEmpty().

Such utilities are useful, but no compiler in the world can force us to use them. We are not protected from writing wrong code — all variations shown in the previous section are still allowed. We need a better solution.

Could we eradicate null and only use empty strings to represent the absence of a string value? If you read my previous articles (especially Union Types in the Practical Type System (PTS) and Null-Safety in the Practical Type System (PTS) ), then you know already that this is not an option.

We need null!

What if we eradicated the empty string?

Can we do that?

Should we do that?

Yes and yes!

What might at first look as an unforgivable, barbaric act of destruction will turn out to be a wonderful simplification that increases reliability and makes us sleep better at night!

We can even go a step further.

A string is a sequence/collection of characters or Unicode code points (e.g. "foo" is a collection of the characters 'f', 'o', and 'o'). Hence, if we decide to eradicate the empty string, it's reasonable to ask: Does that mean that we should also eradicate empty collections (list, set, map, etc.)?

Again, the answer is a wholehearted yes, we can and should!

However, as we'll see later, we need to do it properly and keep everything practical.

Important
Remark

This article is part of the How to Design a Practical Type System to Maximize Reliability, Maintainability, and Productivity in Software Development Projects series. My suggestion to eradicate empty strings and empty collections concerns only new languages that implement the Practical Type System (PTS) or a similar paradigm designed for reliability.

I do NOT suggest to remove empty strings/collections in existing mainstream languages such as C, C++, C#, Java, JavaScript, Python, and Rust.

In the next section you'll see why we can remove empty strings and empty collections, even though this contradicts established practices and guidelines. After evaluating the pros and cons, it will become clear why we should also remove them. Finally you'll see how it all works in PTS, and a practical example will demonstrate the benefits.

Can We Do It?

If you think that eliminating empty strings and collections is a bad idea, know that you're not alone. We're so used to them that we take them for granted and can't imagine living without them. In this section we'll have a look at some counter-arguments to my suggestion.

Note

Source code examples in this section and the next one are shown in Java, but the concepts discussed are applicable to other programming languages as well.

Argument #1: Empty strings and empty collections are supported in all popular languages and they are used in pretty much all kinds of applications. There must be a good reason for this. We can't eliminate them.

Arguments like "Everybody does it, so it must be right" or "It has always been done like this, so we should do the same" can be flawed.

Staying open-minded for novel ideas, and daring to challenge entrenched concepts (including those that may appear unassailable), is crucial to drive progress.

Note

When I decided to eliminate empty strings and collections in PPL (a proof-of-concept implementation of PTS, now hibernating), I anticipated that I would later regret my idea, after encountering cases that would show me clearly why empty strings and collections are needed (in addition to null). Nevertheless, I decided to just try it out and see what would happen. What did happen was that I never regretted the decision. In the following sections, I'll explain why this turned out to be a beneficial idea (unlike several other ideas that I ultimately had to discard after experimenting with them).

Argument #2: Using empty strings/collections instead of null simplifies code and eliminates some null pointer errors.

Common wisdom dictates that functions ought to return empty strings and collections, instead of null. Lots of articles have been written about this topic, and the advice is supported by many prominent and influential voices. For example, Microsoft states (in Guidelines for Collections): "DO NOT return null values from collection properties or from methods returning collections. Return an empty collection or an empty array instead."

The rationale for this guideline is easy to understand.

Suppose we want to iterate over food in the fridge. If fridge.getFoods() returns an empty collection to represent "no food in the fridge", we can simply write:

for ( Food food : fridge.getFoods() ) {
    System.out.println ( food.toString() );
}

If there's no food in the fridge, the body of the loop won't be executed. We don't need to write:

List<Food> foods = fridge.getFoods();
if ( ! foods.isEmpty() ) {
    for ( Food food : foods ) {
        System.out.println ( food.toString() );
    }
}

On the other hand, if fridge.getFoods() returns null, then a simple loop:

for ( Food food : fridge.getFoods() ) {
    System.out.println ( food.toString() );
}

... results in a null pointer error if there's no food in the fridge (i.e. whenever fridge.getFoods() returns null).

We have to write:

List<Food> foods = fridge.getFoods();
if ( foods != null ) {
    for ( Food food : foods ) {
        System.out.println ( food.toString() );
    }
}

Obviously, it looks like using null (instead of an empty collection) does indeed add unnecessary complexity and increases error-proneness, doesn't it?

Yes, but ... this is not the whole story — we have to look at it from a different perspective. We must reconsider this argument in the context of more reliable software development, which is the primary goal of PTS.

For now, suffice to say that we can use null instead of an empty collection, even if it seems like we shouldn't.

In the next section we'll come back to this essential point.

Argument #3: Sometimes, an empty string/collection has a different meaning than null, and in such cases they must be handled differently in the code. Therefore we need both.

In our introductory example, the meaning of an empty string was the same as for null, because we handled both cases in the same way:

if ( email == null || email.isEmpty() ) {

Whether email is null or empty, the same code is executed: the "then" branch of the if statement. The meaning is the same in both cases: there is no email address defined for the customer.

It turns out that, in practice, the meaning of an empty string/collection and null is always the same, unless we assign them different meanings in specific cases.

For example, we could specify that an empty string means "the customer doesn't have an email address", whereas null means that "we don't know yet whether the customer has an email address or not".

However, this is bad practice, therefore we shouldn't do it. Assigning different meanings to null and an empty string/collection would just be a convention that must be documented and applied everywhere in the code by everybody working on the codebase. This is error-prone, and the compiler can't enforce such conventions.

If we need to differentiate between two (or more) cases then a safe approach is to use different types for the different cases.

For example, consider a function that returns the allergies of a given person. Obviously, it's crucial to differentiate between "this person has no allergies" and "this person has not yet been tested for allergies". It could be tempting to keep it simple and specify that an empty list returned by the function means that the person has no allergies, whereas null means that the person has not yet been tested for allergies. However, this would turn out to be a terrible idea, because every developer needs to be aware of this convention and apply it correctly. Client code would look like this:

List<Allergy> allergies = person.allergies();
if ( allergies == null ) {
    // the person has not yet been tested for allergies
} else if ( allergies.isEmpty() ) {
    // the person has no allergies
} else {
    // the person has allergies
}

Extremely error-prone — we shouldn't do this.

Instead, person.allergies() should return one of three types: AllergiesNotTested, NoAllergies, or HasAllergies (a type that contains a non-empty list of allergies). Client code is now clear and type-safe, other cases could easily be added in the future (e.g. AllergyTestPending), and the compiler checks for cases we might have forgotten. The code looks like this:

switch ( person.allergies() ) {
    case AllergiesNotTested notTested -> {
        // the person has not yet been tested for allergies
    }
    case NoAllergies noAllergies -> {
        // the person has no allergies
    }
    case HasAllergies hasAllergies -> {
        // the person has allergies
    }
}

In a nutshell, code like this:

if ( collection == null ) {
    // do this
} else if ( collection.isEmpty() ) {
    // do something else 
} else {
    // ...
}

... is a code smell. More precisely, it's a data design smell. It means that different semantics (meanings) have been assigned to the cases "the collection is null" and "the collection is empty," instead of using different types for these different cases.

We can conclude:

• The meaning of an empty collection (or an empty string) and null is the same, unless we assign different meanings in specific cases, but we shouldn't do this.

If we don't do what we shouldn't do, the conclusion can be simplified:

• The meaning of an empty collection (or an empty string) and null is the same. They are handled the same way in the code.

Microsoft puts it like this in Guidelines for Collections: "The general rule is that null and empty (0 item) collections or arrays should be treated the same."

Hence, we never need null and empty collections/strings to represent semantically different cases of the absence of a value.

Note

Can we hastily conclude that the integer zero and null (or the boolean false and null) also have the same meaning, in the same sense that an empty string and null mean the same? No, that would be a terrible fallacy. Zero and null, as well as false and null have very different meanings. For example, accountBalance = 0 means that there's no money in the account, while accountBalance = null means that we don't know how much money there's in the account.

Argument #4: Sometimes we need mutable collections, and they must be allowed to be empty — for example to implement stacks, queues, deques, etc.

Yes, that's a valid argument. The short answer (in PTS) is that immutable collections cannot be empty, but the standard library also provides mutable collections that can be empty. This will be covered in a later section.

Argument #5: We need empty collections and null whenever we work with libraries and frameworks (possibly written in different languages) that use both.

Working with third-party APIs is not a problem, because we can simply convert data between the "null and empty" and "only null" worlds. Examples will be shown later.

Conclusion:

As seen in this section we can eliminate empty strings and empty collections, and use null instead.

However, that doesn't mean yet that we should do it. If Bob can write a big application using only Windows Notepad, it doesn't mean that he should do it.

Should We Do It?

In this section we'll look at pros and cons of eliminating empty strings/collections, starting with the pros.

if ( email == null || email.isEmpty() ) {
    writeError ( id + ": no email" );
} else {
    writeInfo ( id + ": " + email );
}

if ( email == null ) {
    writeError ( id + ": no email" );
} else {
    writeInfo ( id + ": " + email );
}

if directory_is_not_empty then
    copy_files_in_directory
else
    report_missing_files_error
.

if no_students_in_the_classroom then
    close_the_windows
    switch_off_the_lights
else
    if its_hot then
        open_the_windows
    .
    switch_on_the_lights
.

// real-life example
if there_are_bugs_in_the_code then
    fix_bugs
else
    work_on_new_features
.

for ( Object element : collection ) {
    // handle element
}

if ( collection != null ) {
    for ( Object element : collection ) {
        // handle element
    }
}

if ( collection != null ) {
    for ( Object element : collection ) {
        // handle element
    }
} else {
    // handle edge case
}

int elementCount = collection.size();
boolean weHaveCheese = foodsInFridge.contains ( "cheese" );

int elementCount = collection == null ? 0 : collection.size();
boolean weHaveCheese = foodsInFridge == null ? false : foodsInFridge.contains ( "cheese" );

fn foo ( strings list<string> ) -> list<integer>
    // body
.

fn foo ( strings list<string> or null ) -> list<integer> or null
    // body
.

fn foo ( strings list<string or null> or null ) -> list<integer or null> or null
    // body
.

const name = "Bob"               // OK
const name = ""                  // compile-time error
const name string or null = null // OK

const numbers = [list 1 2 3]              // OK
const numbers = [list ]                   // compile-time error
const numbers list<number> or null = null // OK

fn int_range ( start integer, end integer ) -> list<integer>
    in_check: end >= start
    
    const builder = list_builder<integer>.create
    repeat from i = start to end
        builder.append ( i )
    .
    return builder.build
.

fn append_elements ( strings mutable_list<string> )
    
    if strings.is_empty
        strings.append ( "first" )
    .
    strings.append ( "foo" )
.

repeat for each number in [list 1 2 3]
    out.write_line ( number.to_string )
.

1
2
3

const commands list<command> or null = get_commands()
if commands is not null
    repeat for each command in commands
        log_info ( """Executing command {{command.to_string}}.""" )
        // code to execute command
    .
else
    log_warning ( "There are no commands to execute." )
.

const commands list<command> or null = get_commands()
if commands is not null
    repeat for each command in commands
        log_info ( """Executing command {{command.to_string}}.""" )
        // more code
    .
.

repeat for each command in get_commands() if_null: skip
    log_info ( """Executing command {{command.to_string}}.""" )
    // more code
.

repeat for each command in get_commands() if_null: throw "'commands' is not supposed to be 'null'."
    log_info ( """Executing command {{command.to_string}}.""" )
    // more code
.

const commands list<command> or null = get_commands()
if commands is not null
    repeat for each command in commands
        log_info ( """Executing command {{command.to_string}}.""" )
        // more code
    .
else
    throw null_iterator_in_loop_error.create (
        message = "'commands' is not supposed to be 'null'.",
        id = "NULL_ITERATOR_IN_LOOP" )
.

fn average_length_of_remarks ( remarks list<string> ) -> decimal
    
    variable sum = 0.0
    repeat for each remark in remarks
        sum = sum + remark.length
    .
    return sum / remarks.size
.

static double averageLengthOfRemarks ( List<String> remarks ) {

    double sum = 0.0;
    for ( String remark : remarks ) {
        sum+= remark.length();
    }
    return sum / remarks.size();
}

fn average_length_of_remarks ( remarks list<string or null> ) -> decimal or null
    
    variable sum = 0.0
    variable remarks_count = 0
    repeat for each remark in remarks
        if remark is not null
            sum = sum + remark.length
            remarks_count = remarks_count + 1
        .
    .
    return if remarks_count =v 0 then null else sum / remarks_count
.

fn average_length_of_remarks ( remarks list<string or null> ) -> decimal
    
    variable sum = 0.0
    repeat for each remark in remarks
        if remark is not null
            sum = sum + remark.length
        .
    .
    return sum / remarks.size
.

fn average_length_of_remarks ( remarks list<string or null> or null ) -> decimal or null

    if remarks is null then return null

    // rest of code
.