A Case for Guard Clauses

One of my pet peeves in programming is that few people use guard clauses. A guard clause is an almost trivial concept that greatly improves readability. Inside a method, handle your special cases right away and return immediately.

Have a look at the following example:

private int doSomething() {
    if (everythingIsGood()) {

         * Lots and lots of code here, but that's a different story.

        return SOME_VALUE;
    } else {
        return ANOTHER_VALUE;  // a special case

You can easily rewrite it using the Replace Nested Conditional with Guard Clauses refactoring from Martin Fowler’s Refactoring:

private int doSomething() {
    if (! everythingIsGood()) // <-- this is your guard clause
        return ANOTHER_VALUE;

     * Lots and lots of code here, but that's a different story.

    return SOME_VALUE;

Once you’ve read past the conditional(s) at the beginning of the method, you know that your world is in order and you don’t have to worry about special cases anymore.

This entry was posted in best practices and tagged , , . Bookmark the permalink.

8 Responses to A Case for Guard Clauses

  1. David Linsin says:

    I think this is related to the notion of “fail-fast”, right? Which I wrote about here: http://dlinsin.blogspot.com/2008/07/how-to-fail-fast-on-faulty-injection.html

  2. mafr says:

    Yup, it’s definitely related. But catching special cases early can also help to simplify your algorithm, much beyond my trivial example.

  3. Christoph Schmitz says:

    I think this is a result of the doctrine that every method should have exactly one exit, which has been tought (and might be tought today) in many programming classes.

    While your first example actually has two exits, it’s quite similar to the style that you often see which has one “returnValue” local variable per method and exactly one “return returnValue” statement at the end.

    • Geek says:

      That’s a valid strategy in C to make sure that all memory and locks allocated is freed again. Newer programming languages provide a garbage collector and synchronization has gotten a part of the language. So it’s not that important any more.

  4. mafr says:

    @Christoph: Yup. This could perhaps date back to Dijkstra’s “Notes on Structured Programming” from 1969. But if you want to program this way, you should also be forced to provide a correctness proof :)

  5. Yannick says:

    From my point of view, if everything is not good then it should throw an exception.

    If a special case just return a different value because of a different argument then its not a special case to me, that’s just the standard program flow.

    Throwing exception will keep best of both world: fail-fast and one return statement per method.

  6. Zoran says:

    You’ve got the point with the last paragraph – “you know that your world is in order”. The problem with methods is that they accept types that define sets of values that are greater than the set of values the method can handle.

    In some cases you can try to reduce the method’s domain like here http://www.codinghelmet.com/?path=howto/why-do-we-need-guard-clauses – if method’s domain is the same as the domain of the type it receives through arguments, then we’re safe and there will be no guard clauses.

    Unfortunately, all reference types keep null as part of their domain, and methods must at least guard against nulls then.

Leave a Reply to mafr Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s