| I generally agree with you, but it depends on how obvious the semantics of the code are. In your example, noNameDateFiltered is most likely superfluous. If the filter function is short it's self-descriptive what it does. Adding long variables names makes the code harder to read and adds cognitive overhead. In this case, I would strongly prefer just re-using arr or a. On the other hand, I have seen long complex function that use single-letter variable names and end up with 20 variables that mean different things. Keeping track of what's what in such a case becomes difficult, and you want something more descriptive. Taking a step back, the goal of variable names is to make the code easily comprehensible by someone else or you at a later time. You have a few choices to do this, in order of preference: - The code is self-explanatory, like a simpler filter function - use a short simple variable names. This is always the preferred method. Why make it harder than it needs to be? Reading over-the-top verbose code is just as bad as the opposite. - The code expression may cause confusion - use a more descriptive variable name, but don't go overboard - It's difficult to describe the result succinctly even with a variable name - use comments |
Never overestimate this, there is no upside to the one time it isn't.
> Reading over-the-top verbose code is just as bad as the opposite
No it isn't, it is just as easy, and when can help it pays off, there is no downside.
> It's difficult to describe the result succinctly even with a variable name - use comments
This isn't an either or, if it deserves a comment by all means use one, but that doesn't negate the benefits of thoughtfully named vars.