from Hacker News

The Ruby Style Guide

by garrettdimon on 6/14/19, 2:19 PM with 47 comments

• by pjungwir on 6/14/19, 4:31 PM

  Oh fun another style discussion! :-)

  My own taste is for a "book style": write the code like you see in good books. I agree with most of this guide, although I'm pretty loose and case-by-case in practice. I've gradually added rubocop to lots of my projects, but then I wind up disabling tons of the rules.

  I'm sad all the Ruby guides I've seen ban "and" and "or". I don't find them to be such an issue, and they are nicer to type & read. For one thing you can say `foo or raise "msg"` but need parens to say `foo || raise("msg")`. On team projects I sigh and go along with it, but it is a shame.

  Speaking of "book style": I have a bunch of Python books with atrocious style, e.g. no spaces between operators or even between function arguments. How can anyone read that? I even see this from high-quality publishers like O'Reilly. What is going on with the Python world? Are their thumbs tired from all that indentation, so they leave out spaces everywhere else? ;-)

  I really want to write a SQL style guide. There seems to be almost no consensus. My own formatting is idiosyncratic and not super principled, but I feel it is the most readable and expresses structure the best. It looks like this:

      SELECT  a, b
      FROM    t1
      LEFT OUTER JOIN t2
      ON      t2.t1_id = t1.id
      WHERE   t2.c = 'foo';
  

  (EDIT: Sorry, t2.c = 'foo' is a pretty dumb thing to do in an outer join. :-)

  Other people like to do one or more of these things:

      SELECT a
           , b
        FROM t1
             LEFT OUTER JOIN t2 ON t2.t1_id = t1.id
       WHERE t2.c = 'foo';
  

  In other words:

  - lead with the comma in SELECT.

  - ragged left edge but line up all the single spaces in a column.

  - indent the joins.

  Anyway sorry for the rambling. :-) There is some observation that committees spend 90% of their time on trivial details and hardly discuss any of the important stuff, and style is no exception. But who doesn't like giving their opinion? :-)

• by danmaz74 on 6/14/19, 5:17 PM

  The only thing I really don't like here is non indenting when inside case. I know that technically it's not a block, but in practice I find it much less readable

• by steveklabnik on 6/14/19, 4:34 PM

  I made a comment on this thread[1] in 2014, and it was closed two days ago. I wondered why... guess this is why!

  1: https://github.com/rubocop-hq/ruby-style-guide/issues/273

• by intsunny on 6/14/19, 8:45 PM

  I'll never understand Ruby's obsession with implicit return.

  When reading code, my eye will immediately notice the `return` keyword and will have less to think about in terms of code execution.

  The `return` keyword makes for great readability.

• by onnnon on 6/14/19, 8:00 PM

  There's also StandardRB, it's like StandardJS but for ruby:

  https://github.com/testdouble/standard

  Lightning talk about it here:

  https://www.youtube.com/watch?v=uLyV5hOqGQ8

  Edit: I posted it on its own if you want to discuss:

  https://news.ycombinator.com/item?id=20186231

• by h1d on 6/14/19, 4:19 PM

  Hard to swallow without any reasons written behind each decisions.

• by hderms on 6/15/19, 1:47 AM

  All languages should have gofmt at this point. Debating code style is a waste of everyone's time.

• by weeksie on 6/14/19, 6:24 PM

  Parens for method calls should only be used when things get ambiguous. Nothing bugs me more than seeing ruby code cluttered up with that garbage. I know, I know, but that's my personal bikeshed and I'll happily die on the roof of it.

• by pswenson on 6/14/19, 5:19 PM

  80 char line length in 2019?

• by abakus on 6/14/19, 8:02 PM

  How about 1 space indentation? Just to be able to squeeze even more stuff into the 80 char limit? 0 space is a bit too extreme :)

• by tigrezno on 6/14/19, 6:01 PM

  Spaces for identation? seriously?