Programming Patterns I Like

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

(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();

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

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.

    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.

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.

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.

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.

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.

    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), {});

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);

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.

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

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

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.

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.

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