2 ms·

A minor style point, but you can drop the parentheses here. They're only needed when you're assigning the result of the comprehension since = has a higher prece

A minor style point, but you can drop the parentheses here. They're only needed when you're assigning the result of the comprehension since = has a higher precedence. I go back and forth on whether it's better to remember this or to just put parens all the time.

runeh 16y ago
The parentheses thing is the one thing that bugs me a bit about the CS syntax, but mostly when dealing with calling functions. I wouldn't mind omitting the parentheses around function arguments if I could be consistent about it. Seems like there are some cases where parentheses are necessary to make sure args go with the right function. I'm wondering why I find this so annoying though. It's not like I complain about having to put parentheses in math to make sure stuff is evaluated with the precedence I want.
- grayrest 16y ago
  The way I think of it is "is this function call (including arguments) the last item on the line". If the answer is yes, you can drop the parens otherwise you have to keep them. E.g. foo bar baz 2 # is foo(bar(baz(2))) foo bar baz(), 2 # is foo(bar(baz(),2)) foo bar().baz 2 # is foo(bar().baz(2)) In every case, the foo is the last item on the line. In the second there's an argument after the call to baz() so it's not the last thing on the line and needs parens. In the third, baz is being chained off bar so bar is not the last thing on the line and needs parens. In general I'd do all the parens except maybe the ones for foo in the second and third cases simply because it takes a minute to figure out where the calls get split when you re-read the code. I tend to drop the call parens in situations the following: # DSLish things task 'foo', depends: ['bar'] # Callback/lambda taking things xhr_get url, -> stop_animation() That actually covers a fairly wide set of use cases for me since I tend to write DSLish/callback code but for things like `add(2,2)` I write in the parens regardless of position.

runeh 16y ago

The parentheses thing is the one thing that bugs me a bit about the CS syntax, but mostly when dealing with calling functions. I wouldn't mind omitting the parentheses around function arguments if I could be consistent about it. Seems like there are some cases where parentheses are necessary to make sure args go with the right function. I'm wondering why I find this so annoying though. It's not like I complain about having to put parentheses in math to make sure stuff is evaluated with the precedence I want.

grayrest 16y ago
The way I think of it is "is this function call (including arguments) the last item on the line". If the answer is yes, you can drop the parens otherwise you have to keep them. E.g. foo bar baz 2 # is foo(bar(baz(2))) foo bar baz(), 2 # is foo(bar(baz(),2)) foo bar().baz 2 # is foo(bar().baz(2)) In every case, the foo is the last item on the line. In the second there's an argument after the call to baz() so it's not the last thing on the line and needs parens. In the third, baz is being chained off bar so bar is not the last thing on the line and needs parens. In general I'd do all the parens except maybe the ones for foo in the second and third cases simply because it takes a minute to figure out where the calls get split when you re-read the code. I tend to drop the call parens in situations the following: # DSLish things task 'foo', depends: ['bar'] # Callback/lambda taking things xhr_get url, -> stop_animation() That actually covers a fairly wide set of use cases for me since I tend to write DSLish/callback code but for things like `add(2,2)` I write in the parens regardless of position.