3 ms·

Agree nearly 100%, except I see no problem with omitting parentheses around arguments in method definitions. I've never had any trouble parsing this and it's a

Agree nearly 100%, except I see no problem with omitting parentheses around arguments in method definitions. I've never had any trouble parsing this and it's a bit cleaner to my eye.

OriginalSyn 14y ago
In team environments you typically sacrifice convenience for maintainability and while you may not have a problem with optional parenthesis, it invites ambiguity and a more junior programmer may make a mistake because of it so the idea is to close off that edge case completely and not have to worry about it. This is the same reason a lot of shops ban the terniary operator for anything more than the simplest of variable assignments. It's not saying it's not useful, it's just that there are cases where if they had just been there in the first place coding errors could have been avoided.
- danenania 14y ago
  I agree with your general point, but I don't really see how omitting those parentheses invites ambiguity. def reply_to_post text end What could anyone imagine text to be in this context aside from an argument? I get that using parentheses is more familiar coming from languages with C syntax, but I see no other rationale. I've never worked with anyone who stumbled over this. It's always just: 'oh cool, I didn't realize you could omit parentheses there.'
  - OriginalSyn 14y ago
    I may have been thinking of a edge case in CoffeeScript when I wrote that, but you're right.
  - xentronium 14y ago
    It just doesn't scan well. It's quite easy to misread this as reply_to_post_text, for example.
yxhuvud 14y ago
Agreed, unless the definition line spans multiple lines. Then ()'s are necessary for readability.
lucisferre 14y ago
I think the issue is around the ambiguity and cognitive friction associated with figuring out where you require them and where you don't. Generally speaking I don't have a lot of problems with it, but I could see why someone might just say "always" to this one.

Agree nearly 100%, except I see no problem with omitting parentheses around arguments in method definitions. I've never had any trouble parsing this and it's a bit cleaner to my eye.

OriginalSyn 14y ago

In team environments you typically sacrifice convenience for maintainability and while you may not have a problem with optional parenthesis, it invites ambiguity and a more junior programmer may make a mistake because of it so the idea is to close off that edge case completely and not have to worry about it. This is the same reason a lot of shops ban the terniary operator for anything more than the simplest of variable assignments. It's not saying it's not useful, it's just that there are cases where if they had just been there in the first place coding errors could have been avoided.

danenania 14y ago
I agree with your general point, but I don't really see how omitting those parentheses invites ambiguity. def reply_to_post text end What could anyone imagine text to be in this context aside from an argument? I get that using parentheses is more familiar coming from languages with C syntax, but I see no other rationale. I've never worked with anyone who stumbled over this. It's always just: 'oh cool, I didn't realize you could omit parentheses there.'
- OriginalSyn 14y ago
  I may have been thinking of a edge case in CoffeeScript when I wrote that, but you're right.
- xentronium 14y ago
  It just doesn't scan well. It's quite easy to misread this as reply_to_post_text, for example.

yxhuvud 14y ago

Agreed, unless the definition line spans multiple lines. Then ()'s are necessary for readability.

lucisferre 14y ago

I think the issue is around the ambiguity and cognitive friction associated with figuring out where you require them and where you don't. Generally speaking I don't have a lot of problems with it, but I could see why someone might just say "always" to this one.