`no-use-before-define` with arrow functions and the top-to-bottom/the stepdown rule Clean Code principle.
See original GitHub issueWhat 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.
- Add a new option
arrow-function
that checks for arrow functions afterlet
andconst
- Added behavior: Check if
lowerLevelFunction
is called inside another function (higherLevelFunction
) and only throw an error ifhigherLevelFunction
is invoked beforelowerLevelFunction
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.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:6 (5 by maintainers)
@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.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.