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

1–10 of 73 posts

Re: Github Ruby Styleguide

#2

Post by NateDad »

I'm not a Ruby programmer, but a couple of these things just look completely wrong:

# good

def some_method(some_arr)

  some_arr.size
end

Omitting the return statement is a good thing? How do you know if this method even returns anything? .size could be a method that doesn't return anything, right, since parens are optional?

#good

do_something if something_else

This, to me, is horrible.

If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off.

Also, it's incredibly hard to process when I'm mentally executing the code in my head. Generally if there's a method call on the left, you just do it... but now we hit this if statement, ok, so mentally undo the method call we just processed, now check the if statement... now skip back to the do_something and reapply the method call... and now skip the if statement and continue on in the code.

...or you could just do if something_else then do_something (if you really must have single line if statements, which I am also against, but not so much as the if statement after the method it's controlling access to)

Re: Github Ruby Styleguide

#3

Post by [deleted] »

NateDad wrote: post #2

I'm not a Ruby programmer, but a couple of these things just look completely wrong: # good def some_method(some_arr) some_arr.size end Omitting the return statement is a good thing? How do you know if this method even returns anything? .size could be a method that doesn't return anything, right, since parens are optional? #good do_something if something_else This, to me, is horrible. If you're just scanning down the…

[deleted]

Re: Github Ruby Styleguide

#4

Post by lucian1900 »

NateDad wrote: post #2

I'm not a Ruby programmer, but a couple of these things just look completely wrong: # good def some_method(some_arr) some_arr.size end Omitting the return statement is a good thing? How do you know if this method even returns anything? .size could be a method that doesn't return anything, right, since parens are optional? #good do_something if something_else This, to me, is horrible. If you're just scanning down the…

Returning the last expression is quite handy for a lot of functional patterns. One gets used to it very quickly, especially one has used lisp at all.

Parens being optional is indeed a flaw in Ruby's design.

Post-if can be handy, sometimes.

Re: Github Ruby Styleguide

#5

Post by matt_yoho »

NateDad wrote: post #2

I'm not a Ruby programmer, but a couple of these things just look completely wrong: # good def some_method(some_arr) some_arr.size end Omitting the return statement is a good thing? How do you know if this method even returns anything? .size could be a method that doesn't return anything, right, since parens are optional? #good do_something if something_else This, to me, is horrible. If you're just scanning down the…

> Omitting the return statement is a good thing? How do you know if this method even returns anything?

In Ruby, all methods return the value of the last expression executed in the method.

> .size could be a method that doesn't return anything, right, since parens are optional?

This is in theory true but never happens in practice.

Edit: Ruby has no "non-method" properties on objects. Everything is a method call, regardless of use of parens.

> If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off.

An experienced Rubyist would catch it, if not at first glance, with the second. This is used relatively sparingly, and in scenarios conceptually similar to an early bailout return statement. It makes sense where it makes sense, if you will.

Neither of these is a problem in practice. It may be an issue of familiarity and comfort with the language, but in my experience it doesn't take long to be comfortable with either of those conventions.

Re: Github Ruby Styleguide

#6

Post by xentronium »

NateDad wrote: post #2

I'm not a Ruby programmer, but a couple of these things just look completely wrong: # good def some_method(some_arr) some_arr.size end Omitting the return statement is a good thing? How do you know if this method even returns anything? .size could be a method that doesn't return anything, right, since parens are optional? #good do_something if something_else This, to me, is horrible. If you're just scanning down the…

> Omitting the return statement is a good thing? How do you know if this method even returns anything?

All methods return something.

> If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off.

This is actually one of the arguable points in that styleguide. Some people share your disapproval for inline if modifiers. Anyway it's not that bad after getting used to as long as lines aren't too long and predicates aren't too complex.

Re: Github Ruby Styleguide

#7

Post by xentronium »

lucian1900 wrote: post #4
NateDad wrote: post #2

I'm not a Ruby programmer, but a couple of these things just look completely wrong: # good def some_method(some_arr) some_arr.size end Omitting the return statement is a good thing? How do you know if this method even returns anything? .size could be a method that doesn't return anything, right, since parens are optional? #good do_something if something_else This, to me, is horrible. If you're just scanning down the…

Returning the last expression is quite handy for a lot of functional patterns. One gets used to it very quickly, especially one has used lisp at all. Parens being optional is indeed a flaw in Ruby's design. Post-if can be handy, sometimes.

> Parens being optional is indeed a flaw in Ruby's design.

This flaw allows us to have nice DSLs unencumbered with parens.

Re: Github Ruby Styleguide

#8

Post by yalue »

I agree with almost everything except for using named groups over the $1-$9 variables in regular expression matching. This may be the case if there are many capture groups in the expression, but I would argue that

    /(?regexp)/ =~ string
is a fair deal more difficult to read than simply

    /(regexp)/ =~ string
Almost everybody familiar with PCRE will be familiar with the simpler form, and it's usually the case that the shorter the regular expression, the easier it is to understand and read.

Re: Github Ruby Styleguide

#9

Post by NateDad »

xentronium wrote: post #6
NateDad wrote: post #2

I'm not a Ruby programmer, but a couple of these things just look completely wrong: # good def some_method(some_arr) some_arr.size end Omitting the return statement is a good thing? How do you know if this method even returns anything? .size could be a method that doesn't return anything, right, since parens are optional? #good do_something if something_else This, to me, is horrible. If you're just scanning down the…

> Omitting the return statement is a good thing? How do you know if this method even returns anything? All methods return something. > If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off. This is actually one of the arguable points in that styleguide. Some people share your disapproval for inline if modifiers. Anyway it's not that bad after getting…

> All methods return something.

Ahh, that helps, thanks.

Re: Github Ruby Styleguide

#10

Post by Karunamon »

I'm a little curious why

    %w(strings go here)
is preferred to

     [strings, go, here]
The first form requires extra work to escape spaces, the second form is a representation of an array everywhere in Ruby, including in the debugger and IRB.
Post reply on HN