`no-use-before-define` with arrow functions and the top-to-bottom/the stepdown rule Clean Code principle.

What rule do you want to change? no-use-before-define

The no-use-before-define makes it so you cannot follow the ‘top-to-bottom’ principle or ‘the stepdown rule’ from the book Clean Code (by Robert C. Martin or Uncle Bob if you will) when declaring arrow functions. You can get around this by sticking with using the function keyword, but I (and I assume others) would like to use arrow functions instead because of the different behavior of this.

I think this change behavior is important because it’s nice to be able to have an abstract function at the top of your file that explains the behavior of the rest of the file. This function can call other functions that abstract uninteresting details.

Does this change cause the rule to produce more or fewer warnings? Fewer

How will the change be implemented? (New option, new default behavior, etc.)? I have a couple suggestions.

1. Add a new option arrow-function that checks for arrow functions after let and const
2. Added behavior: Check if lowerLevelFunction is called inside another function (higherLevelFunction) and only throw an error if higherLevelFunction is invoked before lowerLevelFunction is declared. This would need to be checked multiple levels deep of course, but I’m sure you get the point.

Please provide some example code that this change will affect:

Before:

// .eslintrc.js
"no-use-before-define": ["error", { 
      "functions": false,
      "classes": true,
      "variables": true }]

// app.js
const higherLevelFunction = () => {
       // stuff

       const abstractedStuff = lowerLevelFunction(); // no error

       // more stuff
};
const lowerLevelFunction = () => {
       // do something
      return something
};

After

// .eslintrc.js
"no-use-before-define": ["error", { 
      "functions": true,
      "classes": true,
      "variables": true,
      "arrow-functions": false }]

// app.js
const higherLevelFunction = () => {
       // stuff

       const abstractedStuff = lowerLevelFunction(); // no error

       // more stuff
};
const lowerLevelFunction = () => {
       // do something
      return something
};

What does the rule currently do for this code? Throw errors about no-use-before-define when it should not happen

What will the rule do after it’s changed? Consider arrow functions as an exception or check the order of function calls like I explained earlier.

[kaicataldo]

@ljharb Thanks for sharing your thoughts! For what it’s worth, I agree with you.

If we were to add this change, I do think it should include non-arrow function expressions as well. That being said, I’m not entirely convinced this meets our bar of being absolutely necessary. It also feels like it could make things confusing if we not all variables are covered under the variables option.

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.