No rule for “Hoisting”

The section “Hoisting” does a good job of explaining the ins and outs of hoisting, but states no rule about that.

For example I consider this a bad practice, because it leads to confusion and possible bugs:

function example() {
  superPower(); // => Flying

  function superPower() {
    console.log('Flying');
  }
}

[gregersrygg]

I’m used to reading code top-to-bottom – and function hoisting is the only thing in JavaScript which breaks that rhythm.

I’d say it’s the rather opposite. With this rule you have to read the code backwards:

function c() {}
function b() { c(); }
function a() { b(); }
a();

Instead of:

a();
function a() { b(); }
function b() { c(); }
function c() {}

As far as I know, there are no side-effects of hoisting named function definitions, and it gives you the ability to have functions ordered in a more natural order. So my vote (if I have one 🐒) goes for relaxing this rule with “nofunc”.

The section for Functions is also kind of meaningless when it’s not allowed:

Why? Function declarations are named, so they’re easier to identify in call stacks. Also, the whole body of a function declaration is hoisted, whereas only the reference of a function expression is hoisted.

[jesucarr]

@ljharb you are right, in the actual implementation it will go inside a function so when called will have the right value. Overlooked that when doing the code simplification.

The design is based on the graphql interface type, like here, so I can’t redesign it.

But thanks for the clarification.