|
|
|
|
|
by cirrus3
1268 days ago
|
|
If nothing else, do it for the increased search scope... you can never predict when someone later is going to be desperately searching any reference to something and when digging into an issue with "foo" then the var name of "fooOutputDirectory" is going to save time vs if you named it "out" or "o". There is no excuse about "well maybe the controller/service/repository/whatever should have been named foo* in that case, I was just holding this temp var for 2 lines of code in helper function and it shouldn't matter".... just don't. Don't be that person. No one thinks you are smarter or cooler for that. Also consider that if you are really using tiny-scoped vars so often, maybe you are doing something else wrong. If you have "data = arr.filter(n => n.flag === true);" and it is so tightly scoped, why do you even need "data"? Maybe just return it... if you need to do some other operation on "data", maybe chain the call? If you need to do literally anything else (even just logging it), name it it something useful. "n" is fine here. "arr" is not... wtf is contained in "arr", what are these types that have "flag"? Sounds like you got slammed in a code review by someone who has had to debug this type of stuff more than you and you are looking for validation. Just stop being this way sooner than later. |
|