Put functions at the end?

[qpwo]

Is there any rule or plugin that would be function definitions at the end of their scope? Ideally with autofix

// Before/incorrect
function f() {
  return 5
}
const x = f()
function g() {
  function h() { return 6 }
  return h()
}
const y = g()

// After/correct
const x = f()
const y = g()
function f() { return 5 }
function g() {
  return h()
  function h() { return 6 }
}

https://stackoverflow.com/questions/69869636/eslint-rule-to-always-put-functions-at-the-end

[chiefmikey]

Not that I've come across, but I'm a bit curious why you'd prefer that. Yes with the way you are declaring your functions hoisting will take care of it, but it can simply get confusing especially for anyone else that ends up working in your code when functions are used before they are declared. It's also not compatible with ES6's block level bindings so it would limit your capabilities or require a lot of rearranging to refactor later. I'm not here to tell you how you to write your code, just want to give you a heads up that I'm not the only one that feels this way!

[qpwo]

Well I was thinking that it would add meaning to the const f=()=>{}/function f(){} distinction. If you had the "functions always at the bottom" rule enabled, then the const f would mean the function really had to be declared at that point. And the main effect of the function would be visible at the top in one contiguous block.

I wonder -- I think it would lead to some confusion and problems as you pointed. I wonder how that weighs against the above point, and how strong the above point is. It would be hard to tell without using the rule for a good while in a large codebase.

My broader motivation for this is that you want code to be as declarative/"graphical" as possible, and depend on order as little as possible. For example, circular dependencies are fine with functions, but lead to errors when you export computed values, because the execution order is unknown/variable and determines the behavior. So putting functions at the bottom essentially bifurcates a module or function into procedural code and declarative code.

That's my hypothesis anyway... I might try to make this rule to see.

[qpwo]

I actually had an absurd proof-of-concept idea called "orderless js" where assignments to computed values were completely forbidden. So you would write something like this:

function f() {
  const d = a() * 2
  const a = () => b + c
  const b = 5
  const c = 10
  return d()
}

Then you could sort your lines alphabetically or do whatever you wanted with the statement order because it wouldn't effect the result. I think it would be completely untenable for large projects, but it's the closest thing to declarative programming in JS I think you can get.

[qpwo]

I wonder in what situation exactly it would require a manual refactor or cause problems / have an unexpected effect?

[chiefmikey]

Thanks for your replies, that is a very interesting and thought provoking explanation, also a good reason to want autofix while experimenting. I think it's really cool that you are wanting to bend javascript to work in this way, pushing the boundaries of a language with ideas like yours is what will keep them alive. The process of building this rule yourself might even be beneficial to developing it further. I can't think of any technical reasons why it might need to be refactored, just purely preference and trends. Thanks again for sharing!