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

The Ruby Style Guide

rubystyle.guide

Post reply on HN
Print view View original

21–30 of 48 posts

Re: The Ruby Style Guide

#21

Post by hartator »

steveklabnik wrote: post #18
hartator wrote: post #17

Earlier quoted context omitted.

Oh, got you. I thought you were implying some conspiracy to kill conversation or something. Nvm.

Ah, yeah, no worries! I was not :)

It's actually an interesting thread. My take would have been to use comma when it's something we intend to modify, no comma when it's not. So intent is explicit.

Like:

    STATES = [
      :success,
      :error
    ]

    SUPPORTED_LANGUAGES = [
      "en",
      "es",
      "fr",
    ]

Re: The Ruby Style Guide

#23

Post by pjungwir »

saghm wrote: post #19
pjungwir wrote: post #4

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

> 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 I generally prefer `&&` and `||` for purely aesthetic reasons; they're much taller characters, so I can easily see the division between clauses. `and` and `or` look too much like identifiers (even with keyword syntax highlighting), so my eyes tend to gloss over them at first glance. Out…

> Out of curiosity, was the use of `&` in "type & read" intentional to try to demonstrate your point?

Ha ha, no! :-) I think I often type "&" as a micro-tie and "and" as a macro-tie. In other words "&" connects two words (or "a, b, & c"---and btw always with an Oxford comma, which should be obviously correct to any self-respecting programmer :-) but "and" connects clauses. This comment is probably the longest I've ever thought about it, but I do believe it is a persistent habit in my typing. Maybe to be consistent I should start using "|" too. :-)

I've never thought about tall/short for Ruby conjunctions, but it seems like a plausible motivation. Lots of typographers say people read by seeing ascenders|descenders (okay that one was on purpose :-) and can even recognize words where the letters are removed and you just draw an outline around them.

EDIT: I think I've been working too hard this week. Bikeshedding style it not normally how I'd spend my Friday morning, but it's pretty fun. :-)

Re: The Ruby Style Guide

#24

Post by weeksie »

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.

Re: The Ruby Style Guide

#26

Post by ddebernardy »

pjungwir wrote: post #4

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

> 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")`.

To me your example seems to be the proper use of the `and` and `or` statements - unless the team decided that the `raise("msg") unless foo` variation was preferable.

Re: The Ruby Style Guide

#27

Post by ghostbrainalpha »

danmaz74 wrote: post #10

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

Everyone agrees with you on readabilty. I think that's why they had to add this bit about this (A bit of History) section...

"This is the style established in both "The Ruby Programming Language" and "Programming Ruby". Historically it is derived from the fact that case and switch statements are not blocks, hence should not be indented, and the when and else keywords are labels (compiled in the C language, they are literally labels for JMP calls)."

Re: The Ruby Style Guide

#28

Post by saghm »

pjungwir wrote: post #23
saghm wrote: post #19

Earlier quoted context omitted.

> 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 I generally prefer `&&` and `||` for purely aesthetic reasons; they're much taller characters, so I can easily see the division between clauses. `and` and `or` look too much like identifiers (even with keyword syntax highlighting), so my eyes tend to gloss over them at first glance. Out…

> Out of curiosity, was the use of `&` in "type & read" intentional to try to demonstrate your point? Ha ha, no! :-) I think I often type "&" as a micro-tie and "and" as a macro-tie. In other words "&" connects two words (or "a, b, & c"---and btw always with an Oxford comma, which should be obviously correct to any self-respecting programmer :-) but "and" connects clauses. This comment is probably the longest I've ev…

Those are all really interesting points! The division between clauses and lists is a really great insight; I think for me, I actually have the opposite preference ("&" for clauses and "and" for lists), although in practice I don't find myself using "&" in English very much.

> people read by seeing ascenders|descenders (okay that one was on purpose :-)

I actually totally missed that you had done that until you pointed it out :)

> and btw always with an Oxford comma

Now we've definitely found some common ground!

Re: The Ruby Style Guide

#29

Post by yxhuvud »

ghostbrainalpha wrote: post #27
danmaz74 wrote: post #10

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

Everyone agrees with you on readabilty. I think that's why they had to add this bit about this (A bit of History) section... "This is the style established in both "The Ruby Programming Language" and "Programming Ruby". Historically it is derived from the fact that case and switch statements are not blocks, hence should not be indented, and the when and else keywords are labels (compiled in the C language, they are l…

No, everyone does most assuredly not agree on readability when it comes to case statements. Flat case reads better, and indenting it would be like indenting "elsif" and "else" in an else statement.

Re: The Ruby Style Guide

#30

Post by davnicwil »

pswenson wrote: post #11

80 char line length in 2019?

I know, on the surface it seems silly, but there are a couple of reasons I've found 80 chars makes things easier in real world workflows in 2019:

* Split panes in editors. With 80 chars, you can usually have two panes on screen along with a file tree, on most laptop screens. This is pretty nice to have.

* Code reviews in a web interface like Github/Gitlab - 80 chars means usually there's no need to pan, even when your browser window isn't full screen

Post reply on HN