Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Github Ruby Styleguide

github.com

Post reply on HN
Print view View original

71–73 of 73 posts

Re: Github Ruby Styleguide

#71

Post by xentronium »

danenania wrote: post #28
OriginalSyn wrote: post #22

Earlier quoted context omitted.

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 variab…

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 realiz…

It just doesn't scan well. It's quite easy to misread this as reply_to_post_text, for example.

Re: Github Ruby Styleguide

#72

Post by gurkendoktor »

alanctgardner2 wrote: post #33
pooriaazimi wrote: post #30

Earlier quoted context omitted.

Well, I expect first_user = User.find(4) && second_user = User.find(6) to be literally equivalent to second_user = User.find(6) first_user = User.find(4) && second_user I honestly can't see why you might want it to mean something else... Edit: I see. if you do something like if (first_user = User.find(4) && second_user = User.find(6)) { .. } it might bite you. You might expect it to be equivalent to first_user = User…

Personally, I'm almost painfully verbose with my parens to avoid exactly this scenario. Better to be explicit about my intent to the interpreter and other coders. Having an assignment that could be skipped by short-circuiting also seems like bad practice, but I realize it was designed to be a toy example

Skipping the second assignment if I don't need it is more of an optimisation. The "long form" would be,

first_user = User.find(4) if first_user second_user = User.find(6) if second_user ... end end

Re: Github Ruby Styleguide

#73

Post by gurkendoktor »

pooriaazimi wrote: post #30
alanctgardner2 wrote: post #29

Earlier quoted context omitted.

> first_user = User.find(4) && second_user = User.find(6) It looks like it would evaluate as: first_user = (User.find(4) and second_user = User.find(6)) That is to say, the assignment comes after the boolean operation, which is unexpected.

Well, I expect first_user = User.find(4) && second_user = User.find(6) to be literally equivalent to second_user = User.find(6) first_user = User.find(4) && second_user I honestly can't see why you might want it to mean something else... Edit: I see. if you do something like if (first_user = User.find(4) && second_user = User.find(6)) { .. } it might bite you. You might expect it to be equivalent to first_user = User…

> Parenthesis should always be used when there's even the slightest possibility that you or another maintainer/contributor might be confused about.

Yes, but you can make the same point in favor of using "and" and "or" (and deprecating &&/||).

Post reply on HN