3 ms·

A bit OT, but may I suggest for a style guide to not use the shorthand, w/o brackets, in single-argument arrow functions, as in var wait = ms => new Promise(

A bit OT, but may I suggest for a style guide to not use the shorthand, w/o brackets, in single-argument arrow functions, as in var wait = ms => new Promise((r, j)=>setTimeout(r, ms)) Here, the semantics of "ms" are not resolved by its lefthand side, but only by its righthand side (i.e., if this was anything but an arrow, "ms" would be a value assigned to "wait", while here it's the beginning of a functional construct, spanning over the rest of the line.) Opposed to this, using brackets for arguments anytime conveys the meaning much more clearly: var wait = (ms) => new Promise((r, j) => setTimeout(r, ms)); Edit: The amount of look-ahead introduced by the shorthand syntax is rather foreign to JS, as is the switch in syntax that goes with the number of arguments (as illustrated by the example). I'm not convinced that this was the greatest idea in the history of JS syntax ever.

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.
rmrfrmrf 9y ago
Some style guides enforce your proposal, but I prefer less noise where possible, especially for currying. const plugin = store => next => action => foo(store, next, action) vs. const plugin = (store) => (next) => (action) => foo(store, next, action)

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.

rmrfrmrf 9y ago

Some style guides enforce your proposal, but I prefer less noise where possible, especially for currying. const plugin = store => next => action => foo(store, next, action) vs. const plugin = (store) => (next) => (action) => foo(store, next, action)