I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
Hey! I'm YCMJason, a Software Engineer in London 👨💻. Love diving into tech puzzles and sharing them! 🧩
All views expressed here are my own opinions, so please take them with a pinch of salt! 🧂
I am quite against writing all functions as arrow functions. The reason being that arrow functions are not bind-able and it refers to the this from the outer scope. I feel that it is designed to prevent us writing var self = this; and refer to self in a callback function. So I tend to write arrow functions only when it is a callback or when it is a one-off function. Also if we use arrow function instead of proper function declaration in this case, we will lose the advantage which function hoisting provides. This means range might not be accessible by some earlier parts of our code. But it is all down to personal preference, do tell me what you think.
I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
I don't like ambiguity in code. When I'm reviewing code and have to stop and figure out what this is referring to, it makes me frown; with arrow functions I always know exactly what this is. The 'swap this and that' pattern in JS always struck me as a hack. One of the big wins of arrow functions is eliminating the this ambiguity.
I have a similar feeling for hoisting. I understand why it is part of the language, but it always feels like a path to ruin when I have to rely on some behind-the-scenes reshuffling by the interpreter to get my code to run.
All that said, you are correct that there are situations in which arrow functions are not appropriate, which also make me crazy. Having two ways to write functions just adds confusion. "We recommend using arrow functions everyhwere. Oh, sorry, was that a constructor? Write that one this way instead..."
I can't wait to start seeing code in review that's built with templated classes. Maybe ES7 will introduce header files...
Hey! I'm YCMJason, a Software Engineer in London 👨💻. Love diving into tech puzzles and sharing them! 🧩
All views expressed here are my own opinions, so please take them with a pinch of salt! 🧂
Haha! I totally understand what you mean. But still since ES6 introduces class we should really move away from using function as a constructor. As soon as it is consistent in a team then it's fine.
I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
Also, I'm a big fan of using variable names that describe what they are (even for internal functions), so (line break for readability on dev.to) const range = (start, end) => new Array(end - start + 1)
.fill(undefined).map((value, index) => index + start)
Hey! I'm YCMJason, a Software Engineer in London 👨💻. Love diving into tech puzzles and sharing them! 🧩
All views expressed here are my own opinions, so please take them with a pinch of salt! 🧂
On the other hand, I am a big fan of Haskell. And we tend to use _ to refer to variables which we don't use in the function. But I do agree with you that having meaningful names is a good practice and could help readability.
I'm on the faculty at Boston University in the computer science department, where I teach software engineering, intro courses, and application architecture and development. Also a bit of a Deadhead.
Even in Haskell, _ is a bad idea :) Think about the poor intern trying to learn the language while debugging your code. (And it isn't just Haskell...I did a lot of Perl back in the day, which at it best can look like line noise).
BTW since you are a fan of Haskell, I ran across this article the other day that you might enjoy, describing how to structure JS function with Haskell-styl currying.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you're going to use => might as well go all in... (line break for readability on dev.to)
const range = (start, end) => new Array(end - start + 1).fill(undefined).map((_, i) => i + start)
I am quite against writing all functions as arrow functions. The reason being that arrow functions are not bind-able and it refers to the
thisfrom the outer scope. I feel that it is designed to prevent us writingvar self = this;and refer toselfin a callback function. So I tend to write arrow functions only when it is a callback or when it is a one-off function. Also if we use arrow function instead of proper function declaration in this case, we will lose the advantage which function hoisting provides. This meansrangemight not be accessible by some earlier parts of our code. But it is all down to personal preference, do tell me what you think.I don't like ambiguity in code. When I'm reviewing code and have to stop and figure out what this is referring to, it makes me frown; with arrow functions I always know exactly what this is. The 'swap this and that' pattern in JS always struck me as a hack. One of the big wins of arrow functions is eliminating the this ambiguity.
I have a similar feeling for hoisting. I understand why it is part of the language, but it always feels like a path to ruin when I have to rely on some behind-the-scenes reshuffling by the interpreter to get my code to run.
All that said, you are correct that there are situations in which arrow functions are not appropriate, which also make me crazy. Having two ways to write functions just adds confusion. "We recommend using arrow functions everyhwere. Oh, sorry, was that a constructor? Write that one this way instead..."
I can't wait to start seeing code in review that's built with templated classes. Maybe ES7 will introduce header files...
Haha! I totally understand what you mean. But still since ES6 introduces
classwe should really move away from usingfunctionas a constructor. As soon as it is consistent in a team then it's fine.Also, I'm a big fan of using variable names that describe what they are (even for internal functions), so (line break for readability on dev.to)
const range = (start, end) => new Array(end - start + 1).fill(undefined).map((value, index) => index + start)
On the other hand, I am a big fan of Haskell. And we tend to use
_to refer to variables which we don't use in the function. But I do agree with you that having meaningful names is a good practice and could help readability.Even in Haskell, _ is a bad idea :) Think about the poor intern trying to learn the language while debugging your code. (And it isn't just Haskell...I did a lot of Perl back in the day, which at it best can look like line noise).
BTW since you are a fan of Haskell, I ran across this article the other day that you might enjoy, describing how to structure JS function with Haskell-styl currying.