Back to recent posts

blog

Application Development, ,

Short-circuiting in .NET February 16th, 2010

Randall Davis

Randall Davis

No Comments

Mixx This  /  Save to del.icio.us  /  Share on Facebook

In the Microsoft .NET Framework, regardless of the particular language in which you write your code, the compiler breaks it down into a lower-level language called CLR (Common Language Runtime). The most popular .NET languages are Visual Basic.NET and C#.NET, but because both are broken down in the same way, they’re identical by the time a program is run. Because of this, the particular language that you use is exclusively a matter of preference.

I’ve put in a good amount of time with both Visual Basic.NET and C#.NET, and my personal preference is C#.NET. Usually, developers gravitate toward the language that they’re most familiar with (which is often C#.NET for those who come from a C++ or Java background, and Visual Basic.NET for those who have a Visual Basic background). In my own case, it all comes down to a single gripe about Visual Basic.NET: it doesn’t handle “short-circuiting.”

Here’s a simple function that takes in a string in the form of “LastName, FirstName”, and returns the last name in C#.NET, written in long form with elementary techniques:

public string parseLastName(string fullName) {

    //ensure that fullName is not null:
    if(fullName!=null) {

        //ensure that a comma exists in the string:
        if(fullName.Contains(',')) {

            //return the part of the string leading up to the comma:
            return fullName.Substring(0, fullName.IndexOf(','));
        }
    }

    //something went wrong, so return null:
    return null;
}

These “if” statements are necessary because “fullName.Substring(0, fullName.IndexOf(‘,’))” will throw an error or behave unexpectedly if the string is blank, or if it doesn’t contain a comma. Also, “fullName.Contains(‘,’)” will throw an error if fullName is null.

C#.NET has something called “short-circuiting,” which makes it stop comparing and return a result as soon as possible. For example, the code above can be simplified into this:

public string parseLastName(string fullName) {

    //if the string is valid, return the part of the string leading up to the comma:
    if(fullName!=null && fullName.Contains(','))
        return fullName.Substring(0, fullName.IndexOf(','));

    //something went wrong, so return null:
    return null;
}

This is a nice, clean way to write the code, because the two conditions of the “if” statement accomplish the same objective: I just want to see if fullName is valid for parsing. In the first example, you’re not sure why I’m checking to see if fullName is null, because that bit of code is on its own. I like the second example a lot better, because it’s easier to read.

Because of short-circuiting, if fullName is null, C#.NET won’t check to see if fullName has a comma, because there’s no reason — the “if” statement as a whole is already demonstrated to be false. Not only does this make the code execute more efficiently, but it protects my code, because if fullName is null, and “fullName.Contains(‘,’)” is executed, my code will throw an error.

The same code written in Visual Basic.NET would needlessly execute “fullName.Contains(‘,’)”, and would break my program. This may seem like a very small thing, but because comparison logic is so necessary to any block of code, this very small thing can really pile up, and takes a big toll on the readability of your code.

Careers

We are looking for experienced professionals to join us and contribute to our clients’ success.

View Opportunities