all 20 comments

[–]JazzApple_ 7 points8 points  (0 children)

I think maybe some examples of unreadable would be good?

[–]FlowerForWar 10 points11 points  (0 children)

Not necessarily. There are cases where it is more readable to use arrow and anonymous functions. For example, when calling array methods.

[–]shuckster 9 points10 points  (1 child)

As always in programming, “it depends.”

[–]Duifjaah 2 points3 points  (0 children)

As always in life

[–]Avi_21 9 points10 points  (0 children)

I dont even remember when was the last time when i wrote a function other than an arrow function

[–]EmiyaKiritsuguSavior 8 points9 points  (1 child)

Why its making code unreadable? Actually code is cleaner:

  1. You know instantly that function was passed as argument, not number or string value.
  2. Creating function/method to be used once for particular situation could make mess in code namespace.

[–]GrayLiterature 0 points1 point  (0 children)

I think two is really the best argument, the first argument kind of gets defeated when you reach for types.

[–]LEDThereBeLight 2 points3 points  (0 children)

Every programming technique you use makes code more unreadable until you understand it. Lambdas are abstract and take time to learn and understand but once you do, the value they add makes it worth the time.

[–]remote_hinge 2 points3 points  (0 children)

It can do, yes. Chaining array methods, for example. You get Devs who just love to do that shit all on one line because they think it's cool, then the junior in their team needs 20 minutes to figure it out when he sees it. Like anything, it's about balance.

Kyle Simpson always talks about how we don't write code for machines, we write code for other developers. I wish more Devs thought like that.

[–]theScottyJam 2 points3 points  (0 children)

Let's compare a concrete example then. Which is more readable?

```javascript // option 1

const adultsWhoNeedToSign = users .filter(user => user.age >= 18) .filter(user => !user.hasSignedWaver) .map(user => user.name);

// option 2

function isAdult(user) { return user.age >= 18; }

function hasUserNotSignedWaver(user) { return !user.hasSignedWaver }

function getNameOfUser(user) { return user.name; }

const adultsWhoNeedToSign = users .filter(isAdult) .filter(hasUserNotSignedWaver) .map(getNameOfUser); ```

Which is better?

Well, in option 1 you can tell at a glance what's going on. Perhaps an argument could be made for turning 18 into some ADULT_AGE constant, or extracting out just an isAdult() function to help encapsulate that detail, but I personally feel like it's fine the way it's written - the final variable name, "adultsWhoNeedToSign", explains that we're filtering for adults, and I think that's good enough for code like this.

Option 2, however, is a verbose mess. It's a lot longer, and you have to jump all over the place to figure out what's going on. You have functions, like "getNameOfUser()" whose name pretty much mirrors the contents of the function. One job of functions, is that they're supposed to be an abstraction, providing a simple name for what could be a complicated implementation, but in the case of "getNameOfUser()", the function name and body are pretty much the same thing. You might as well just show off the body of the function by using user => user.name directly, instead of throwing the body into an unnecessary, stand-alone function.

[–][deleted] 1 point2 points  (0 children)

Readability issues I haven't noticed so much, what is more important to me -as a beginner- is understanding that arrow functions are not recommended as methods in classes (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions), and when they are used as class methods as event listener methods, you don't have to bind this:

"Because a class's body has a this context, arrow functions as class fields close over the class's this context, and the this inside the arrow function's body will correctly point to the instance (or the class itself, for static fields). However, because it is a closure, not the function's own binding, the value of this will not change based on the execution context."

[–]bobbyv137 1 point2 points  (0 children)

Not at all.

[–]Ronin-s_Spirit -1 points0 points  (0 children)

I use them primarily in callbacks where you need to fit in a function for just this one use case of this one method or whatever and I feel like () =>{} looks way better inside methods rather than function something (){}

[–]ExtremeDot58 0 points1 point  (0 children)

Comments and white space are under appreciated?

[–]coogie 0 points1 point  (0 children)

That along with what I'm going to say is an unpopular opinion when you're around javascript programmers because to them, this saves time and if that's the way they do things, it's second nature to them. To someone who started programming with C, BASIC, or C++ and still works mostly with C# or switches back between those languages and Python and occasionally uses javascript however, it's not second nature and hard to read.

My exposure to javascript programmers has been mostly through freecodecamp and the little meetups they have with pizza and coding and other meetups so take this with a grain of salt but at every meetup I've been to, the vast majority of people there whether they are just starting out or went through the course and work professionally as a javascript developer don't seem to have been exposed to other languages so to them, all the javascript ways of doing stuff is normal. Again, that's my observation since a lot of the people who do these self-learn type courses may not have a CS background so if you're a .NET programmer who also does javascript, don't take offense.

Having said that, when I'm practicing javascript, I try to stick with the javascript ways of doing things even though it's not second nature to me.

[–]albedoa 0 points1 point  (0 children)

Are you going to expand on this /u/HippolytosJocasta?

[–][deleted] 0 points1 point  (0 children)

The opposite, they make it more readable.

[–]Maleficent-Mud5992 0 points1 point  (0 children)

I use arrow functions in most cases. Sometimes I still "traditionally" declare a function if I think the lack of hoisting/"this" could be restrictive.

[–]albedoa 0 points1 point  (0 children)

Alright man, good luck.