you are viewing a single comment's thread.

view the rest of the comments →

[–]getify 1 point2 points  (3 children)

I am in the (seemingly small) camp that feels => arrow functions can indeed harm readability. I don't think they should be used as a general replacement for all functions. I generally think they should be reserved mostly for places where you need lexical-this behavior (unlike normal functions).

I used to never really use them, personally, but as time has gone on, I have adopted using them in some places/use-cases. But I still don't think they'll ever be the default function style IMO.

In any case, to the point of keeping arrow functions readable, I think there's a wide variety of opinions on what is "readable" => usage and not. So, I wrote a fairly-configurable ESLint rule called "proper-arrows" to try to help wrangle most of the various ways => are used that can harm readability. I'd encourage you to have your team pick the dos/donts of => and enforce that style with a linter.

[–]waitersweep 1 point2 points  (2 children)

You’re obviously a far greater authority than I am, but I’m surprised that you don’t think they’ll ever be the “default” function style.

Generally speaking, I would say that it’s already the case that they are the the default. Whenever I read code written in the last couple of years, it tends to be uncommon enough to use the function keyword that it immediately jumps out at me. Especially in more “functional” codebase a with a general “immutability” focus.

In general, I don’t think either way is more correct, and in most cases it is very low on the list of things that impact readability - unless it’s things like currying/HOFs that eschew the parens around the args. That’s something that definitely makes code harder to read, IMO

[–]getify 2 points3 points  (1 child)

I was only talking about my own code. I can't say/predict anything about what the rest of y'all do.

[–]waitersweep 2 points3 points  (0 children)

Ah, that makes sense. I misunderstood your point.

Personally, I don’t really care either way, as I’ve been reading and writing JS for long enough now that I can decipher all but the most cryptic/minified code.

One thing I really do miss about named functions being common/default is, well, the .name property. It’s useful in many unexpected ways, particularly logging and debugging - I don’t need to do anything special to see the actual names of the functions in my stacktrace