Conditional logic is the third hardest thing just after variable naming and cache invalidation. There is no excuse to make it harder to understand.

  const result = (() => {
    if (!conditionA) return 'Not A';
    if (conditionB) return 'A & B';
    return 'A';
  })();

However, I’m not sure how this is supposed to be “written far more concisely”? It’s more verbose, involves more different constructs, more levels of indirection - pretty much for any definition of “conciseness“ I can think of, it is worse.

  if (condition) { do_x() } else { do_y() }

    const x = cond1 ? a 
            : cond2 ? b
            : c

    let x = if cond1 { a }
            else if cond2 { b }
            else { c }

(The example is also a bit misleading, since the logic flow between the nested ifs and the chained ternaries are subtly different.)

In the provided example, const result = !conditionA ? "Not A" : conditionB ? "A & B" : "A";

is really equivalent to:

  const result = null;

  if (!conditionA) {
    result = "Not A";
  } else if (conditionB) {
    result = "A & B";
  } else {
    result = "A";
  }

  function checkConditions() {
    if (!conditionA) {
      return "Not A";
    }
    // A is true from here onwards.
    if (!conditionB) {
      return "A";
    }
    // B is also true from here onwards.
    return "A & B";
  }
  
  const result = checkConditions();

That language doesn't have an "elseif", so you're actually writing the shorthand for

    if(!a) {
      ...
    } else {
      if(!b){
        ... 
      } else {
        ...
      }
    }

https://www.typescriptlang.org/docs/handbook/advanced-types....

I must say that I find those examples clearly express what is going on.

Also, about another poster's comment, while it may be true that for regular code needing this may be a sign that the code needs refactoring, for business logic this is not true. You may very well end up with "business logic code" where things like huge functions and long nested conditionals actually are the optimal way to express messy reality, and that trying to use refactoring methods like "put this into extra functions" actually increases complexity.

Simple chained ternaries like in the example really aren’t hard to reason about. They are a sequence of conditions, each followed by a `?`. The first condition that evaluates to true will return the value after the `?`. If none evaluate to true, the value after the final colon is returned.

You can chain as many ternaries as you want and follow the same simple rules to understand what they return.

EDIT: The example in the article is rather unfortunate though, as the if statement is nested in a different way than the ternary, for unclear reasons.

       result = (cond_A ? 1 :
                 cond_B ? 2 :
                 cond_C ? 3 : 
                 5)

    conditionA
      ? conditionB
        ? ‘A + B’
        : ‘A’
      : ‘Not A’;

This is a matter of practice. It doesn’t take that many times thinking about it to understand how this works in general (it’s always the same).

Write a generic function for this instead? Lodash has one like this called "partition" for example.

I try and avoid explicit for loops as much as possible as they tend to make code harder to follow and state manipulation is a big source of bugs. Most operations on collections can be decomposed into some easy to follow combination of map, reduce and filter instead (this is a filter variation).

Nice article!

My knee jerk response was to disagree, being that reduce is well known to mean fold / accumulate. However I've seen a lot of js usages where it does things like modify structures in the containing scope and isn't an FPish fold at all, so a name like that could probably make a lot of sense.

Nonetheless for this particular usage, I'd agree that a more specific partition function like lodash's would be an improvement.

TFA’s inlined reduce version is much less readable than calling a function which wraps this behavior up.

First the practical, in my experience, a big function with many early returns has a bug or has a convoluted logic, 100% of the time. I've literally made a living and a career by untangling big functions with early returns. I've really saved many situations and code just by doing that. The reason this happens is that early returns are gotos and gotos are harder to follow.

Also, you can't move easily (think copy/paste) code than has early returns, which means that the code is defacto harder to refactor. So in practice, code with early returns stays in place and grows.

Early returns are artefacts of the assembly jump instruction. They shouldn't even be in a high-level programming language because it makes no sense to have jumps in such a language. They make the programmer lives in the assembly language world (succession of instructions that update a state) instead of the wonderful world of high-level programming (expressions).

If you interested by what I'm saying, you should try removing all returns, continues and breaks from your code, you'll see what wonderful things happens. It's literally magic. Things becomes so much more expressive without them. Which is the point, high level programming is about gaining more expressiveness over assembly code.

Early returns is one of the big pillars of bad inexpressive entangled convoluted programming. And what is people reason for using early returns? It makes less indentations...

You may wonder why early returns doesn't sound that much like a big deal after all. And you are right, there is no big deal. No big deal in terms of what the market reward. Now if you care about the art of programming, this is a huge deal imo.

edit: thank you for the fair discussion. I would like to insist that obviously, if your code is more expressive, you will take better decisions and at the end, what I'm saying is that you will end up with a totally different program. Early return or not is not about cosmetic. It's about writing better program.

I also write a lot of JS and tend to use guard clauses fairly liberally. I find they make boundaries (x < 0) much clearer. My functions are also < 10 lines in most cases. For me it leads to less convoluted code but YMMV.

Other programming languages let you return from any line in the function, no matter how deep in a conditional, inside nested loops, before or after variable side effects, etc. Tricky to know just _what_ that function will do given some inputs.

    def transform_data(raw_data) when length(raw_data) == 1, do: []
    def transform_data(raw_data) do
        # actual function code goes here
    end

    def transform_data([_|[]]) do: []

I suppose I could get rid of early returns with a variable and breaks, but is it worth it? My functions tend to be small enough for me to not run into problems with early returns.

So are a lot of other constructs:

break is goto the end of the loop, continue is goto the beginning of the loop, the closing of a loop block is goto the beginning of loop, else is goto the end of the conditional, if is maybe goto the next else, and return (early or not) is pop from the stack and goto that address.

The fact that a language feature uses a JUMP instruction does not make it necessarily evil; most of them do. Everything has both benefits and drawbacks which are often highly situational.

You may find it easier to convince people of the problem with early returns if you limit the scope of the argument to a more specific context than “always”: it’s usually easier to make an argument for a concrete case rather than an abstraction, and then show how the same reasoning applies to a large class of situations.

Do I understand correctly that you tend to make large functions because they're easier to refactor (and not returning early makes this easier)?

    Option<T> sink(int pos) {
        if(pos>=this.length()){
          return Nope;
        }
        // code that has depends on the bounds check
        Some(value)
     }

      Option<T> sink(int pos){
         Option<T> ret = Nope
         if(pos < this.length()) {
             // same code
             ret = Some(value)
         }
         return ret;
     }

When rewriting multiple guards you get more empty statements that reassign the default value of the return.

I do have the following opposite opinion too: guards should be simple: no loops, no complex control flow (name the loop). No side effects in guards. And no guards handled by the expected case, even for clarification.

  return pos < this.length() ? Some(value) : Nope

And even then I would reverse the order, placing the exceptional and short case first.

Moving the code: why? You have a perfectly encapsulated function. If you need to, you have more problems with shadowing variables, functions and with return types.

For functional languages: doesn't Haskell explicitly have guard pattern? I thought the general guidelines favored matching and guards over if statements.

LOL. Try adding returns, continues, and breaks where appropriate to some random code that doesn’t currently use them, and you’ll see what wonderful things happen. It’s literally magic. The control flow becomes clearer and more linear and the code becomes more logical and concise, with fewer weird conditionals repeated several times for no reason. Also often improves performance, “for free”.

It seems we have different experiences because where I see early returns used is mostly where functions are already small.

You can certainly over-engineer things just to avoid bigger functions. However from my experience I see that far less than complicated large functions with little care to readability.

Good question. This is true, but this is a programming language bug. In some programming language you can write the equivalent of return if... or return for.... Also note that those intermediate variables add a lot in expressiveness (you're computing result or screensize etc). The mutation is unfortunate indeed but a programming language bug.

But lately I've been working with Elixir which doesn't support early returns and while Elixir does have some tricks up its sleeve to better handle the idea of having an early return without using it (such as pattern matching on function arguments and / or guards), I'm now slowly shifting into thinking early returns in any language makes things more difficult to reason about in the end most of the time.

I say "most of the time" because for very short functions where you might return early to avoid an else clause or deal with varying types of input, that's not too bad. It's really a problem in the use case you explained where you have a larger function that might have 4 or 5 early returns scattered about and that function might be nothing more than having a few short if statements that say "if this, then do_something and return". It becomes difficult to maintain because now the function ends in 5 different spots based on 5 different conditions.

   return rawData && rawData.length > 1 ? rawData.map((item) => item) : []

These small concrete examples are good to talk about. How would you rewrite the following:

    def contains_3(xs):
        """Returns True if the given list contains a 3."""
        for x in xs:
            if x == 3:
                return True
        return False

  def contains_3(xs):
        """Returns True if the given list contains a 3."""
        found = false
        for x in xs && !found: 
            found = x == 3
        return found

In terms of expressiveness (as much as this short example needs expressiveness), note how found is x == 3 which is what you want right. Note how the loop condition is now full. One could also note how every line is about found so you can instantly tell what lines is about found, which one is about foo or bar, if you'd picture a bigger function. Note how there is now only one condition (the loop) and not two (loop and if) (in many situations you would end up with less lines of code, surprisingly). Finally, note how DRY this is: you return x == 3, not True if x == 3 is True (there is many cases where this DRY property is more clearly visible).

This code reads like a list comprehension.

In addition to be more expressive (although, again, this is more striking on a bigger function) and movable, you can also actually write bigger functions like that which you can't with early returns (everybody agrees this is a mess).

If I'd tell you not to use jumps, you would have found that solution. Simply ban jumps from your code (find the alternative way of writing things) and you will obtain a code that will surprises you, especially in bigger functions.

I don't think so, even after seeing your pseudo code don't see a nice way to avoid the early return. I don't understand how your for-loop / if-condition mix works, but let me try to translate it as best I can into valid Python:

    def contains_3(xs):
        found = False
        index = 0
        if not found:
            found = xs[index] == 3
            index += 1
        return found

    def contains_3(xs):
        found = False
        index = 0
        while not found:
            found = xs[index] == 3
            index += 1
        return found

I don't understand why you keep talking about jumps in assembly code. Code which has zero early returns will still have hundreds of jumps in the assembly code.

Code that is short is good. Code that is readable is good. I don't think we'll agree on what code is more readable, but we can at least agree on which code is shorter.

As I've gained programming experience I care less and less about how individual functions are implemented and more and more about what those functions do and what they return. For something like `contains_3`, I see that it is a function with no side-effects, which returns a boolean, and wont fail (at least, wont fail in a language with type checking). This is a small simple function, and I don't care how it's implemented, it is a good function. If it becomes a problem for some reason, it is isolated and can be easily fixed in isolation.

Also beware of people with strong opinions about way too general things in areas where specific things are.. specific, and where discussions of the sort you started are nearly almost a bad sign. Without something concrete to solve/look at these discussions are more religious in nature. You can say whatever, no way to prove or, worse, disprove. When people get into heated discussions there is a good chance that there is no practical test possible because the discussion is not about anything concrete but about "ideas" - where everybody has different ones for the same keyword(s).

And how would putting these early returns in a gigantic if condition or several increasingly indented if blocks fix these bugs? It will not fix any bugs since both forms are equivalent.

>early returns are gotos

All types of control flow can be represented with goto.

>gotos are harder to follow

Harder to follow than what? The majority of programmers are familiar with following gotos by using an abstraction over it such as using loops or if blocks.

>You can't move easily (think copy/paste) code than has early returns

If code is able to be moved to or be copied into another part of the codebase, this is a signal that the piece of code should be put in a function. If you are talking about using a subset of code following early returns, then you do run into the problem in not knowing what subset of early returns (aka preconditions) that are needed to bring be in a new function. This is the same with using large or nested if blocks.

>Early returns are artifacts of the assembly jump instruction

By this logic all control flow constructs are artifacts of that. Regardless whether or not you use early returns, you get equivalent assembly code after compilation.

>it makes no sense to have jumps in [a high level] language

I disagree. It makes perfect sense to have jumps in a high level language. A high level language should allow you to write abstractions over these jumps though. This way you can name and reuse patterns of jumps in your program. In addition you can think of early returns as a high level construct too instead of a low level one. You can think of if blocks as a monad. If we take a look at the article and used nested if blocks you could think of the type of the function as If If List (we can imagine that there is an interpreter behind the scene to convert this into a plain List). Since If is a monad it means we can do the join operation. This would turn it into a single If List. The obvious way to do this transformation by hand to the source file it would be equivalent to merging both if statements into a single one. If the else statements would return different results you would need to make sure you return the value associated with how far into the combined condition you get. Doing it this way is a little awkward. Also remember that monads give us the bind operation too. If we manually transform the source into using the bind operation we actually get the same thing as using early returns. Using early returns is a much clearer implementation of handling the conceptional If monad. By using the If monad we are only having to deal with a single if statement / condition at a time.

>Things becomes so much more expressive

I beg to differ. They are equally expressive, but early returns allow you to mention the preconditions / special cases all at the beginning of your function.

>Early returns is one of the big pillars of bad inexpressive entangled convoluted programming

I'm not sure how early returns make something entangled. Since they can only be at the beginning of a function, they can't really be entangled in your whole function.

>And what is people reason for using early returns? It makes less indentations

Yes, this is a side effect of being a monad. It means we can focus on a single if statement at a time instead of focusing on a bunch of nested if statements at the same time. This is the same thing as when javascript developers realize that converting callbacks that call callbacks, etc into using promises reduces the nesting that is needed.

In summary, I am not convinced from your argument that early returns are bad since they are an abstraction over assembly.

Early exits are fine when they are used for invalid input/use cases. But not for regular algorithmic outputs. This would hide cyclomatic complexity. Unfortunately, not understood by the author once you understand the reduce example. I am not experienced enough with reduce to make a statement about the array pattern... But it looks good especially when the language has array deconstruction.

Guard macro/template/local assertion is almost always better, the key is to not produce too much distracting syntactic noise or work against language features. Redundant rare checks are eaten by branch prediction. (Needs care too, call when Spectre is fixed.)

The big problem for me is that it's offloading the logic for picking to the caller, so that if they forget to default null to ```contentType["default"]``` everywhere there will be a bug. putting the choice+ default fallback at the callee side reduces this boilerplate.

I've generally called a much more general form of this "data driven programming". (The data here being the mapping.)

See: https://en.wikipedia.org/wiki/Data-driven_programming#Anothe... and the referenced https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch09s...

> the important part is moving program logic away from hardwired control structures and into data

    const truthy = [], falsy = [];
    for (const i of values) {
      if (i) truthy.push(i);
      else falsy.push(i);
    }

    const truthy = [], falsy = [];
    for (const i of values) {
      (i ? truthy : falsy).push(i);
    }

    const [truthy, falsey] = exampleValues.reduce((arrays, i) => {
      arrays[+!i].push(i);
      return arrays;
    }, [[], []]);

    group_by = f => (acc, item) => ({...acc, [f(item)]: [...(acc[f(item)] || []), item]});

    const {true: truthy, false: falsy} = values.reduce(group_by(Boolean), {});

2. Yes, similar to my love my avoiding nesting, I too like avoiding indentation. Switch -> Case -> Statement+Break vs Object -> Key/Value.

3. I think this example dips a bit into the arcane. It's not that I can't read it, but you have a reduce starting with two arrays and some conditional logic. I don't often run into it, but I might try to think of where this can apply further.

4. Yes. Even though I love short concise code, I want the variables and function names to be clear to their meaning. When I read acceptable abstract code I expect the pieces to read like a set of instructions. Ideally the nicely named functions do what they say they do, and no more.

5. Hard pass. That ternary looks like a blob of characters and I have to think very hard about the logic going on. Not a... if b then a & b else a... I don't like picking on specific examples inside these kinds of posts, but on first pass:

  if(!conditionA) return "Not A";
  if(!conditionB) return "A";
  return "A & B";

The style I find works best is as follows. Note that alignment of the ? and : characters (and depending on the code style, the parentheses) is vital for the legibility of this style.

  x = (condA) ? (trueA) : (falseA)
      (condB) ? (trueB) : (falseB)
      (condC) ? (trueC) : (falseC)
      (condD) ? (trueD) : (falseD)
      (condE) ? (trueE) : (falseE)
                        : (final case);

  x = (condA) ? (trueA) :
      (condB) ? (trueB) :
      (condC) ? (trueC) : 
      (condD) ? (trueD) : 
      (condE) ? (trueE) : (final case);

  if   (condA) {x = trueA }
  elif (condB) {x = trueB }
  elif (condC) {x = trueC }
  elif (condD) {x = trueD }
  elif (condE) {x = trueE }
  else         {x = (final case) }

It’s definitely superior, since it’s still less noise all around, but almost worthlessly so. And then the same pattern gets covered by switches too...

As for comparison against switches, I find that switches are very limited in a lot of languages (looking at you C/C++). The problem with the if else chain as well is that most code formatters seem to blow it up into the fully expanded form which kills readability.

This will be deprecated as of PHP 7.4[0], and will cause a compile error in PHP 8.0.

However, instead of switching straight to right-associativity, PHP will require explicit parentheses to disambiguate nested ternaries.

[0] https://wiki.php.net/rfc/ternary_associativity

  contentTypes[contentType] || contentTypes['default'];

  contentTypes['hasOwnProperty'] // [Function: hasOwnProperty]
  contentTypes['toString'] // [Function: toString]

I get that the object literal approach feels more functional, and that forgotten break statements will cause havoc tho.

Seems like a safeswitch construct is in order, that does not allow dropthrough. something like:

  safeswitch(s) {
    case 'alpha':
      calc(alpha(x), 2);
    case 'beta':
      calc(beta(x), beta(x*x));
  } else {
    // default case here
    calc(x);
  }

When I've used this pattern in the past I've used a reusable 'getter' object which implements `hasOwnProperty` on itself for the sake of being sure I'm getting only the stuff I want. But it's not quite as concise as what's shown in the example, apart from getting the default internally rather than externally using ||.

I didn't do this for security though, I did it for sanity - I don't want to get false positives when accessing, and the prototype has a ton of properties.

That sort of reads like "I was able to read my own code". That's a good start, but can other people also "quickly understand at a glance"?

So whatever you are used to - you are used to it because your brain wired itself to recognize those patterns. So obviously, when you look at something you are not used to, you are not wired for, it takes a lot longer to process because a lot more of the brain needs to get involved. However, with some time the brain rewires and what was alien now seems completely natural.

Of course, this is within larger limits, you cannot adapt to everything and not to everything at the same speed.

Anyway, my point is, for any such comment people make they should make this test: Do I feel how I feel because of the above, or do I have actual hard knowledge that there is a deeper effect? Meaning, is my comment simply a report of my current wiring state (so, mostly useless to others), or do I have to share actual insights?

Then there's what I wrote in another comment here, about disagreements on waaayyyy to general topics, where people might not actually disagree nearly as much if there was a specific context, but since the topic is so broad everybody comes with their own imagined scenario, depending on their own past experiences, which may very well be best served with very different approaches, but since the discussion remains abstract everybody keeps defending their opinion. Which may actually all be right - for the concrete scenarios they all have in their heads.

For example, there are several commenters here arguing against nested ternaries. I did the same for the longest time. But TypeScript's conditional types require - and officially advertise - exactly this pattern. The way they write it it looks perfectly clear, and I found myself agreeing with there actual concrete code (i.e. types; I posted the link in another comment here).

The 2nd one, there's a caveat about space/GC here.

The 3rd one depends a lot on the situation.

4th one is too obvious for it to be called a pattern, but I agree with it.

5th one is, meh, not really easy to read. I prefer his "bad" example. It could be less verbose, e.g,

if (!conditionA) result = "Not A"

else if (conditionB) result = "A & B"

else result = A

It would be:

  if (conditionA && conditionB) {
    return "A & B"
  }

  if (conditionA) {
    return "A" 
  } else {
    return "Not A"
  }
  
  return "neither A nor B"

return ( (cA && cB && "A & B") || (cA && "A") || (cB && "B") || "neither" );

However, this would also work in Perl, etc, (anything featuring short-circuit evaluation and type coercion for evaluating conditions.)

e.g. (in C# because my JavaScript isn't good):

  interface IContentType {
   void CreateType();
  }
  
  class ContentPost : IContentType {
   public void CreateType() {
    return console.log("creating a post...");
   }
  }
  
  class ContentVideo : IContentType {
   public void CreateType() {
    return console.log("creating a video...");
   }
  }

  void CreateContentType(IContentType contentType) {
   // Instead of a switch, you can now do:
   contentType.CreateType();
  }

    const cases = new Proxy({...cases}, {
      get: (obj, val) => obj[val] || () => {...default case}
    });

  let exampleValues = [2, 15, 8, 23, 1, 32];
  let truthFn = (x) => x > 10;
  let truthyValues = exampleValues.filter(truthFn);
  let falsyValues = exampleValues.filter((x) => !truthFn(x));

Eventually, "structured programming" languages like C and Pascal were invented, where you couldn't just leap from one arbitrary part of the program to another. In these languages, the compiler enforced that each function had a single entry point, solving part of the problem. However, for C in particular the rule was still kind of useful - all the resources allocated during the function needed to be cleaned up by the end, so it was still good practice to have a single exit point that always did whatever cleanup was required.

These days, most languages have a garbage collector that will automatically clean up for you. Languages that don't have a garbage collector, like C++ and Rust, generate all the deallocation logic at compile time (the RAII idiom).

If you're using a language designed after the early 1980s, the "single entry and single exit point" rule is either wholly irrelevant, or does more harm than good.

I personally never use this pattern because I like having a central place to cleanup/set status/return values etc. I also find it easier to add/remove more functionality that way.

The code that I have most often seen using early returns is in large functions that do several things, so they're exacerbating poor design with confusing flow of control.

I feel that if you keep your functions small enough, you can keep them readable either way. So I'm back to mostly worrying about cleaning up resources in a consistent way.

In either case, there's the disadvantage that if you want to do printf debugging and make the function print "function foo returned 'false'" when it returns, early return makes it a pain. (Generally not so much a problem for real cleanup work, since your early returns are likely before the function's actually done any work that needs cleanup)

In functional thinking, it's actually very helpful to think of the edge cases and get them out of the way first. When put in coding, I like to think it's more helpful to let the readers know the purpose of the function first, they could dig deeper later if they choose to.

I found multiple returns were useful places to stick break points[1]. Like when you're trying to track down a rare error condition that happens every so often. Like once a week.

[1] I use a debugger cause I'm a small brained primate.

Run a perf test comparing execution speed on the two strategies. I've had to defend switch like three times this year; there's a reason it exists, it's super easy for compilers to optimize :\

Moreover, mixed-case symbols suck big time.

It is much easier to use descriptive variables than keep the comments up to date.

Additionally, descriptive variables allow anyone to read and more quickly understand the code.

Yes, and I agree 100% with it.

It is much better to write self-documenting code than comments. I just contend that descriptive variable names are not the way to self-documenting code. Of course, I'm talking about local variables whose scope should never go beyond a single screen of code. Globally accessible identifiers (e.g. functions) should of course have very long and descriptive names.

> Additionally, descriptive variables allow anyone to read and more quickly understand the code.

This does not ring true to me, but maybe it depends a lot on the context. At least in numeric mathematics, you always want to name your numbers, vectors and matrices using single letters (as they appear in the corresponding paper). Using "cute" descriptive names hinders a lot the readability of formulas.

I can see where someone writing complex mathematical formulas in C would definitely benefit from single character variable names

Business logic tends to be concrete, not abstract. Mathematics tends to be abstract, not concrete.

Yes, using x,y,a,b,c as names in the quadratic formula makes sense.

But so does "isOverCreditLimit" and "MonthlyInsurancePremium" in business (leaving aside arguments about camelCase etc etc).

Business logic needs to reflect the intent of the business. There is rarely the case for an "x" to "solve for".

Deconstructing a mobile phone plan into code is not the same as deconstructing a math paper. Quantitative mathematics is a very different computing environment to business logic.

> If you put meaning into a variable name that you use twice, then you are repeating yourself, which is very bad. Thus, variable names should NEVER be meaningful (except maybe when they are used only once)

I don't understand this sentence at all. My initial interpretation was that one should only use a variable no more than once which seems completely arbitrary. If a variable is only being used once, that's not a variable, that's a constant — but why are constants more deserving of a meaningful name than a variable, something that could (and should) be used multiple times?

After all, if you're declaring a variable but not modifying it or only modifying it once, you should use a constant — but that still doesn't explain why constants are special enough to merit meaningful names.

Further, you haven't narrowed down to when your assertion applies. What about variables in OOP as members of objects? Should mutating members always have nonsense names?

x = x + 1

is meaningless. Algebraic variables are not the same as what are effectively names for value storage locations, which is the common meaning of a "variable" in most imperative languages.

Of course, with FP, the concept of a mutating variable is frowned upon in general. Mutation is effectively a performance hack.