We Should Eradicate the Empty String — Here's Why

Potentially Troublesome Values Eliminated

The first PTS article introduced the following PTS Coding Rule: "All data types in a software project should have the lowest possible cardinality."

By eliminating the empty string and empty collections, the cardinality of all strings and all collections in every application has been reduced by one.

That's nice.

Even better, we've eliminated the most troublesome values in these types.

As every experienced developer knows, empty strings and empty collections are often invalid values, or they must be handled differently. For example: each name has at least one character; there's at least one student in each class; every online retailer sells at least one product, etc. Eliminating empty values by design eliminates potential bugs related to these values.

Simpler Code

Remember the source code examples from section What's the Problem?, where six programmers wrote different code, and the only correct version was this one:

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

By eliminating empty strings, the risk for wrong code in similar cases (common in many projects) has been eliminated. The correct code becomes simpler, and there's only one right way to do it. In a null-safe language, the check for null is even required by the compiler. We have to write:

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

You don't need to wonder anymore: "Should I check for empty, or null, or both?" We always just have to check for null, and if we forget to do so (on a bad day), the compiler will remind us to do it.

More Reliable Code

The most important point to remember from this article is this: Using null instead of empty strings/collections increases software reliability. Let's see why.

When working with collections, more often than not we need to distinguish between the following two semantically different cases, and we have to handle them individually:

• There are no elements.

• There are one or more elements.

Some pseudo-code examples:

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
.

Sometimes, we forget to distinguish between these two cases — typically, we forget to write specific code for the "no elements" edge case. This can result in bugs that remain undetected during the development and test phases, especially for edge cases that occur rarely.

The good news is this: If we use null (in a null-safe language) to represent "there are no elements" then we can't ignore these edge cases anymore, because the compiler gently reminds us to handle them. In other words, we are always required to handle both cases (i.e. "there are elements" and "there are no elements"). This eliminates many potential bugs.

If we use empty collections, we are allowed to write code like this:

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

An empty collection simply results in "do nothing" behavior. Sometimes this is the right thing to do, but usually it isn't. It's easy to overlook the "there are no elements" edge case. Moreover, if the code was written by somebody else, we don't know if the author intended to do nothing in case of an empty collection.

On the other hand, in null-safe languages that enforces null instead of empty collections, the above code wouldn't compile anymore. We'd have to write:

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

... or:

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

Yes, the code is a bit more verbose if no special handling is required for the "no elements" case, but there are two advantages:

• We can't accidentally forget the "there are no elements" edge case.

  On a bad day we could still forget to add an else branch (whenever needed to handle the edge case), but the risk of this bug is largely mitigated since the test for collection != null is required.

• The programmer's intention to handle or ignore the edge case is clearly stated in the code.

You'll later see a practical PTS example demonstrating the benefits.

Simpler and More Reliable APIs

If strings and collections can't be empty, their APIs becomes simpler and less error-prone.

For example:

• There's no need for an isEmpty method.

• Method size (aka length, which returns the number of elements in the collection) never returns zero. This eliminates the potential risks of some bugs, such as a division by zero when computing the average value in a list of numbers.

• Methods first and last always return an element (instead of returning null or throwing an exception if the collection is empty).

• Methods like allMatch, noneMatch, and anyMatch can't return unexpected and debatable results that can lead to subtle bugs in edge cases.

  People have different opinions of what these methods should return if the collection is empty — as can be seen in the following long discussion in the CodeProject lounge: .NET's Sometimes Nonsensical Logic.

• Methods that compute an aggregate value (e.g. sum, average, min, max) also become more straightforward.

  For example, we don't need to debate questions like "What should function average do if the list of numbers is empty? Return zero? Return null? Throw an exception?"

More Efficient Code

When it comes to time- and space-efficiency, nothing beats null.

In most languages, null is super fast.

Assigning null to an object reference is typically implemented by simply assigning zero (all bits at 0) to a pointer, and checking for null is done by comparing the pointer to zero. Both are CPU operations that are extremely fast.

Better Code Analysis

If collections can't be empty then loops and iterations involving them are always guaranteed to execute at least once. This certainty can be leveraged by advanced compilers (and complementary tools such as static code analyzers) to make assumptions that can't be made if the body of the loop might be executed. For example, a compiler might be able to optimize target code for loops that are guaranteed to execute at least once.

Disadvantages

So far we've talked about advantages. Are there disadvantages too?

The only disadvantage I can think of is the occasional added verbosity. For example, instead of writing:

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

... we have to write:

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

Yes, sometimes the code is more verbose — but that's a small price to pay for all the benefits we've seen so far. We can't have our cake and eat it too. On the plus side, the code is also more expressive and (in some cases) less error-prone because, again, the "no elements" edge case is handled explicitly in the code.

Non-empty Immutable Collections

PTS strings and collections are immutable and non-empty. The following types are defined in the standard library:

• Type string: an immutable string that cannot be empty (i.e. the string must contain at least one character).

• Types list, set, map, etc.: immutable collections that cannot be empty (i.e. the collection must contain at least one element).

These are the types predominantly used in function signatures (i.e. immutable and non-empty). For example, the following function takes a non-empty, immutable list of non-empty, immutable strings as input, and returns a non-empty, immutable list of integers:

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

If input and output are allowed to be null (i.e. there might be "no elements"), the signature will contain union types (t1 or t2), like this:

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

If the input and output lists are also allowed to contain null elements, the signature is as follows:

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

No Empty Literals

Because strings can't be empty, there is no empty string literal, as shown below:

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

There aren't any empty collection literals either:

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

Immutable Collection Builders

While literals are convenient for hard-coding predefined values, builder types allow us to programmatically create strings and collections. For example, we use a list_builder to build a list.

Builders apply the Builder pattern, commonly used in object-oriented languages. Internally, a builder uses a mutable data structure (e.g. a mutable list) to build the collection. An immutable collection is built in three steps:

• Create a builder object (e.g. list_builder.create)

• Add elements (e.g. builder.append ( ... ))

• Create a non-empty, immutable collection by calling builder.build (or builder.build_or_null if there might be no elements)

Here's an example of a function that creates a range of integers:

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
.

Mutable Collections That Can Be Empty

Sometimes we need mutable collections that can be empty. For example: stacks, queues, deques, collections that are populated by several functions, etc.

To keep these data structures efficient and practical, I opted to provide dedicated mutable collections in PTS.

The name of a mutable collection type always starts with the mutable_ prefix, followed by the name of its immutable counterpart. Thus, the standard PTS library provides:

• Type mutable_string: a mutable string that can be empty (i.e. its character length might be zero).

• Types mutable_list, mutable_set, mutable_map, etc.: mutable collections that can be empty (i.e. their size might be zero).

Here's a trivial example of a function that appends one or two elements to a mutable list passed as argument:

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

We can convert a mutable collection into its immutable counterpart (or null if the collection is empty) by calling method to_immutable_or_null (e.g. return customers_found.to_immutable_or_null).

If the mutable collection is assumed to contain at least one element in a given context, the method to_immutable_or_throw should be used: instead of returning null whenever the mutable collection is empty, this method throws an error (exception).

Loops Syntax

We can iterate over collections via a classical loop (imperative style), streams (functional style), or recursion. This section covers only the classical loop construct.

Here's a simple example of using a repeat statement to iterate over a collection:

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

Output:

1
2
3

In cases where there might be no elements, the compiler requires a check for null:

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." )
.

The else branch is optional:

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
    .
.

We can shorten the above code by using the if_null clause in the repeat statement:

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

If a collection is declared to be nullable (either explicitly or via type-inference), but supposed to be non-null in a given context, we can use the if_null: throw clause to abort program execution whenever the collection is null, despite our assumption to the contrary:

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
.

The above code is a shorthand for the following one; both throw an error if the collection is null:

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" )
.

Working with Non-PTS Libraries

Empty strings and collections are ubiquitous in non-PTS libraries. How can we use these libraries in a language where strings and collections can't be empty?

This depends largely on the PTS implementation, but let's consider a PTS implementation that generates Java target code and allows Java source code to be embedded between java and end java statements. Then there are at least three solutions to use Java libraries from within a PTS application:

• Convert input/output arguments

  Before calling a Java library function that doesn't allow null as input, but requires an empty collection, we need to convert null into an empty collection. Here's an example of PTS code using embedded Java:

  java
      sendCommands ( commands == null ? Collections.emptyList() : commands );
  end java

  After calling an external Java function that might return an empty collection, we need to convert the empty collection into null, e.g.:

  java
      List<Command> commands = getCommands();
      if ( commands.isEmpty() ) {
          commands == null;
      }
  end java

  If these transformations are needed often, we can create utility functions that serve as wrappers, so that client code remains idiomatic and succinct.

• Use mutable collections that can be empty

  Instead of converting collections, an alternative solution is to use mutable PTS collections (covered previously in section Mutable Collections That Can Be Empty) to work with non-PTS libraries.

  However, this solution is not recommended, because we lose the advantages of immutable, non-empty collections.

• Use dedicated types to work with non-PTS libraries

  A standard PTS library can provide immutable collections that can be empty, dedicated to be used only when working with non-PTS libraries.

  For example, in my proof-of-concept PTS implementation, I created type emptyable_string (in addition to string and mutable_string). This specific type was sometimes handy — it simplified the task of working with external Java libraries, especially in rare cases where null and an empty string had different meanings.

Unsafe Paradigm

PTS is null-safe and immutable strings and collections can't be empty. However, for the purpose of this exercise, let's first suppose that PTS was designed like many other languages:

• support for null, but not null-safe

• strings and collections can be empty

Now imagine we want to compute the average length of remarks entered by users in a data entry form. Consider the following PTS function to achieve this:

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
.

The code would look similar in many other languages. Here's an example in Java:

static double averageLengthOfRemarks ( List<String> remarks ) {

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

static double averageLengthOfRemarks2 ( List<String> remarks ) {

    return (double) remarks
        .stream()
        .mapToInt ( String::length )
        .sum() / remarks.size();
}

If we call the above PTS function with [list "f" "fo" "foo"] as input, it returns the correct result: 2.0.

Unfortunately, although small and simple, there are three problems:

• If the function is called with remarks = null, a null pointer runtime-error occurs in the repeat statement (for statement in the Java version).

• If the function is called with an empty list as input, a division by zero error occurs in the last statement (because remarks.size is zero).

• Assuming that empty remarks should be ignored, the result will be wrong if input argument remarks contains empty strings. For example, calling the function with [list "foo" "" "foo" ] returns 2.0 (=6/3) instead of 3.0 (=6/2).

  A silently ignored error occurs (worst-case).

Safe Paradigm

Now let's see what actually happens in PTS (which is null-safe and doesn't permit empty strings and collections):

• A function call with remarks = null is not permitted and results in a compile-time error, because all types are non-nullable by default.

• We are also not permitted to call the function with an empty list as input, because collections can't be empty. Hence, a division by zero error cannot occur.

• Input argument remarks cannot contain empty strings, because PTS strings are non-empty too. Therefore, a silently ignored error due to empty remarks cannot occur.

As you can see, all three problems have disappeared. The above function doesn't support the "no remarks" and "some empty remarks" cases, and the compiler ensures that nobody calls the function with invalid input. The function requires a non-null, non-empty list of remarks, and empty remarks are not allowed in the list.

Now suppose that the function should handle empty remarks. Here's the new version:

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
.

Note that:

• The type of elements contained in parameter remarks changed from string to the union type string or null, which explicitly states that empty remark fields are now supported.

• The check if remark is not null is required by the compiler because PTS is null-safe, and remark.length would result in a null pointer error if remark were null at run-time.

• The expression for the return-value if remarks_count =v 0 then null else sum / remarks_count is also required by the compiler. If we simply wrote return sum / remarks_count, the code would not compile, because remarks_count might be zero and thus cause a division by zero (note that this is an advanced compiler feature beyond the scope of this article).

  Because the function might return null, we are also required to change the output type from decimal to decimal or null.

  This, in turn, means that the caller of the function can't forget to handle the edge case where all remark fields are empty, and therefore an average length of remarks could not be computed. We're always safe.

What about variable remarks_count, which is needed to compute the correct result if there are empty remark fields? Suppose we incorrectly wrote:

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
.

Does the compiler report a bug?

No, it doesn't, because the above code would be correct if we actually wanted empty remarks to be included in the computation of their average length.

As said already in a previous PTS article, the slogan "if it compiles, it works" is just wishful thinking. We still need to write unit tests to detect logical bugs.

Now let's consider the "there are no remarks" edge case. The function doesn't currently handle this case. Therefore, the caller of the function is required to explicitly handle this case (if it occurs). However, if we want the function itself to also handle this case, we can easily do this:

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
.

Now the function returns null when called with remarks = null.

Conclusion

Hopefully, these simple examples demonstrate the benefits of a null-safe language that doesn't permit strings and collections to be empty.

Imagine a big application with hundreds or even thousands of edge cases similar to the above ones. Having a compiler that spots all edge cases, including the most elusive ones, is like having a helpful, reliable companion, always by our side, tapping on our shoulder from time to time and telling us: "Look! Here's an edge case that needs to be handled or ignored explicitly."

Nikki Giovanni wisely said:

We can easily apply this insight to the field of software development:

Fail fast!

Non-null-Safe Languages

Many popular programming languages support null, but aren't null-safe. Should new languages applying this paradigm also restrict immutable strings/collections to be non-empty?

Yes, if software reliability matters.

The difference between a null-safe and a non-null-safe language is this: In a null-safe language we get a compile-time error if null is handled incorrectly in the code; in a non-null-safe language we get a run-time error instead — the dreaded null pointer error, whenever a pointer to null is dereferenced.

A null-pointer-error is "bad". But a silently ignored error due to an empty string or collection is "very bad". "Bad" is better than "very bad". It's generally much better for an application to immediately throw a null pointer error and abort program execution than to ignore the problem and silently continue execution with polluted or corrupted data that crawls through the system, and, sooner or later (maybe much later), risks to result in a mysterious bug that's difficult to identify and fix.

Many people hate null pointer errors, but these errors are in fact very useful, because:

• They support the Fail-Fast! principle (at run-time) and the bug is therefore more likely to be discovered early in the development process. The program crashes immediately and noisily, instead of ignoring the problem and silently continuing execution with wrong/corrupted data.

  The final outcome of a null pointer error is usually less severe and more predictable.

  Imagine a nightmarish scenario like this one: Application A writes wrong data into a database. Later on, this data is read and handled by applications B, C, and D. Although the bug originated in application A, it manifests in applications B, C, and D.

• Null pointer errors are usually easy to identify and fix, because their cause and effect are short-distanced.

• Helpful tools capable of identifying potential null pointer errors in the codebase are available for most popular programming languages.

Languages That Use an Optional/Maybe Type

Some languages don't support null. Instead, they provide a dedicated type for cases where a value might be absent. For example, Rust provides the Option type, F# the Option monad, and Haskell the Maybe monad.

The idea of non-empty strings and collections can also be applied in new languages using this approach. Instead of empty strings/collections, the None/Nothing values of the Option/Maybe types are used, respectively, and pattern matching ensures that we distinguish between the "no elements" and "one or more elements" cases, thereby reaping benefits akin to those demonstrated in this article.