Avoid Else, Return Early (2013)

While I think the advice in this post is pretty sound (guard clauses are a great alternative to bailing out of a function in various places, because you can see the conditions up front and not as what is essentially an afterthought), I do take issue with the language we tend to use when sharing advice.

The advice we give is often prescriptive or absolute, in that you have to avoid doing something, or you should never do something, or there is a best practice. More often than not it strips out the nuance, as if the new position has somehow managed to resolve all of the issues that cause the year--even decade--long debates in the first place, and it is far more often the case that the choice is more than preferential.

And what makes it bizarre is evidenced in the article itself: the original, prescriptive position is neutered in a follow-up edit that claims to take the position in balance because it won't make sense in every situation.

The top comment in this thread talks about the evolution of a programmer; surely one of the greater evolutions of your career in the field is to understand that all of this advice is purely dependent on context and an all-or-nothing approach to rule making isn't going to cut it; in fact it will likely make things worse when aspiring programmers take it as gospel and start trying to shoehorn these best practices into whatever code they can, adding all kinds of linters and such to enforce the rules in all cases and prioritizing style over implementation in code reviews. Code must fit in 80 characters in a line; it must omit semi-colons if it's JS; it must use 2 spaces for indentation; it must be extracted into a method if it has more than 5 lines...no matter what.

As an alternative, I instead propose that you think of good or better practices, also known as reasonable guidelines, and if you're going to build a style guide around them at least try to provide some alternatives should the preferred solution not fit the problem the programmer is currently facing. Treat it as an opportunity for mentoring and not just an instruction manual.

In Lisp other structures come into play that effectively give you early return in various situations, like for example cond.

  (cond
    (early-return-condition early-value)
    (second-early-condition early-value2)
    ...
    (t final-else-value))

A cond as the last (or only) form of a body is basically an N-way switch toward multiple exit points, the ones appearing first being earlier.

In TXR Lisp I made block have dynamic scope, not only dynamic binding. You can do this:

   (defun helper ()
     (return-from master 42))

   (defun master ()
     (helper))

I.e. early return from nested helper functions, without a lot of added ceremony.

Speaking of this dialect, here is a function from its C internals, exhibiting a preference for an early return over else:

  val flatten(val list)
  {
    if (list == nil)
      return nil;

    if (atom(list))
      return cons(list, nil);
              
    return mappend(func_n1(flatten), list);                              
  }                                                                                                   

If this were in the Lisp dialect instead of C, the same author would write it like this:

  (defun flatten (list)
    (cond
      ((null list) nil)
      ((atom list) (list list))
      (t [mappend flatten list])))

and certainly not like this:

  (defun flatten (list)
    (when (null list)
      (return-from flatten nil))
    (when (atom list)
      (return-from flatten (list list))
    [mappend flatten list])

Even if the implicit block around a function body were the anonymous block, so that (return (list list)) could be used, this would still be eschewed as unidiomatic Lisp.

I've never seen syntax like 'if (err) return void handleError(err)' before. If I saw that in JS I'd have to look up what it meant.

Tell them braces are visual indicators of blocks of logic, enabling reasoning more easily on a multi-statement level.