3 ms·

Isn't that always the case? You always need to take into consideration the evaluation of the rhs. Consider: var wait = ms * foo() And that's not even consi

by ng12 9y ago

Isn't that always the case? You always need to take into consideration the evaluation of the rhs. Consider: var wait = ms * foo() And that's not even considering the complexity introduced by the comma operator. I think the arrow is the key to visually identifying a function, not the parentheses.

masswerk 9y ago
It's really about the arrow operator starting with "=", which is most likely the beginning of a chained assignment as in a = b = c = 0; Also (as noted in the edit), I'm not the greatest of fans of the syntax switching with the number of arguments. In the example given, there are two arrow functions defined, each of them coming in a different appearance, due to the number of arguments used. Using always brackets, the nature of "ms" and it being used and passed as an argument would be more striking on first sight. Ease of understanding and readability aren't just luxury for a codebase. (The real difference as for pragmatics is this: In any other case, anything on the righthand side of the first "=" is a value resolved on first execution whenever the code is hit, while in this case it's a parameter that becomes evaluated whenever the function defined by this assignment is called – and this relation isn't resolved without look-ahead. Possible errors introduced by a sloppy (mis)reading are numerous.)
- ng12 9y ago
  > is most likely the beginning of a chained assignment I wouldn't think so at all. I almost never do chain assignment in modern JavaScript but I write functions which return functions somewhat often. I guess there's a possibility that someone quickly skimming code would misread => as =. It hasn't yet happened to me though.
  - masswerk 9y ago
    > in modern JavaScript You are probably right on this – but there's still old code around and ease of context switching may be a thing. Also, I guess, you can't be too defensive in your approaches, when setting up a shared codebase that may be around for some time. (With JS being extended on a yearly basis, we hardly can imagine what will be around a few years from now.) Edit: However, also related to modern JS, another possible counter argument to mine: With the omission of terminating semicolons and frequent use of multiline statements determining the semantics has also become a question of scanning the next line anyway. Look-ahead is now a thing.

by ng12 9y ago

masswerk 9y ago

It's really about the arrow operator starting with "=", which is most likely the beginning of a chained assignment as in a = b = c = 0; Also (as noted in the edit), I'm not the greatest of fans of the syntax switching with the number of arguments. In the example given, there are two arrow functions defined, each of them coming in a different appearance, due to the number of arguments used. Using always brackets, the nature of "ms" and it being used and passed as an argument would be more striking on first sight. Ease of understanding and readability aren't just luxury for a codebase. (The real difference as for pragmatics is this: In any other case, anything on the righthand side of the first "=" is a value resolved on first execution whenever the code is hit, while in this case it's a parameter that becomes evaluated whenever the function defined by this assignment is called – and this relation isn't resolved without look-ahead. Possible errors introduced by a sloppy (mis)reading are numerous.)

ng12 9y ago
> is most likely the beginning of a chained assignment I wouldn't think so at all. I almost never do chain assignment in modern JavaScript but I write functions which return functions somewhat often. I guess there's a possibility that someone quickly skimming code would misread => as =. It hasn't yet happened to me though.
- masswerk 9y ago
  > in modern JavaScript You are probably right on this – but there's still old code around and ease of context switching may be a thing. Also, I guess, you can't be too defensive in your approaches, when setting up a shared codebase that may be around for some time. (With JS being extended on a yearly basis, we hardly can imagine what will be around a few years from now.) Edit: However, also related to modern JS, another possible counter argument to mine: With the omission of terminating semicolons and frequent use of multiline statements determining the semantics has also become a question of scanning the next line anyway. Look-ahead is now a thing.