Avoid Else, Return Early (2013)

First, do the simple checks "Oh, this function returns an empty set if one of its parameters is null? Do that".

Then go into the main method body. In the main method body, I want to see elses on ifs. I'm okay with putting a return in each branch of the if/else, but what I find bad is when the main body is

```

  if(foo)
  {
     doLotsOfStufff();
     return myResult;
  }
  return bar;

That pattern I can't stand. That's as confusing as switch-block fallthrough.

For those cases, I prefer to see an else. If you must fall through to a final return while you've had a zillion other returns in your branching logic, then that deserves a comment at least explaining that this is the final fallthrough return.

Like

```

  if(foo)
  {
     doLotsOfStufff();
     if(somePositiveCase)
     {
        return myResult;
     }
     if (someOtherNeutralCase)
     {
        doSomePreparatoryThing();
        if (heyMoreChecks)
        {
           return positiveResult();
        }
     }
  }
  // this comment here is super important where we 
  // explain that we couldn't do any positive thing 
  // so this is a failure state.
  
  return barFail;

To say it is religion isn't to say "your preference is dumb". In my own code preferences I try to maintain a split between "have a reason I have confidence in" and "personal preference". And "easier to read" is almost always in the latter. (If you can say WHY, that is the actual reason, but your actual reason still has to be provable.)

Given the difficulty of finding good research and the inherent difficulty of the research (if familiarity is a big component to preference, and a proven ability to mentally parse code required to judge, then good luck running a control group) I have a lot of items I have confidence in being provable without having actual proof, but the lengthy preference list also means I'm willing to accept that each of those can switch columns.

Way too many of our "easier to read" defenses are really "it is easier to read because I'm familiar with it. I personally think camelCase is terrible - language has spaces for reasons! - but there is no denying that it is very common and that the vast majority of coders learned it first, an unfortunate self perpetuating cycle.

Nonetheless, shown research that said I was wrong (assuming said research had taken familiarity into account) I would change my stance rather than dig in my heels...even if that change were to only add "but that's just me" to the end of it.

Are there any preprocessors or libraries to make statements like this easier in Javascript? Sometimes the guard statements can be longer than the function code and I go back and forth on whether to throw (forces the caller to anticipate) or return (causes lots of silent failures).

It would be great to use a defined approach.

Having a single log line is extremely useful in general as you don't have to filter all the relevant information within other log lines and makes easier to extract a single thread pathway within a multi-threaded application.

however I do like this snippet: > Try keep the “meat” of your method at the lowest indentation level.

but I prefer doing that isolating atomic logics within their own method, instead of having multi-step pathway with early returns