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

31–40 of 48 posts

Re: The Ruby Style Guide

#31

Post by TomMckenny »

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…

A symbol for "or" would be so extremely sensible in this pattern.

And there was one.

Just as "&" abbreviated "et", a-sort-of-i-thingy abbreviated "vel"(= "or"). I have no idea why only "&" thrived and the "or" one faded. Now it's long forgotten, hiding at Unicode point U+026B

Re: The Ruby Style Guide

#32

Post by pjungwir »

TomMckenny wrote: post #31
pjungwir wrote: post #23

Earlier quoted context omitted.

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

A symbol for "or" would be so extremely sensible in this pattern. And there was one. Just as "&" abbreviated "et", a-sort-of-i-thingy abbreviated "vel"(= "or"). I have no idea why only "&" thrived and the "or" one faded. Now it's long forgotten, hiding at Unicode point U+026B

Interesting, thanks for sharing that! I once spent a summer helping a library write one-sentence summaries for medieval Latin books, and all the abbreviations and ligatures made the paleography really tough! But actually we do have a common symbol for "or". I used it once in that comment, but then I switched to "|" for fun: "/".

Re: The Ruby Style Guide

#33

Post by slx26 »

yxhuvud wrote: post #29
ghostbrainalpha wrote: post #27

Earlier quoted context omitted.

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.

yeah, even more, taking the example from the style guide, if lines are short enough, I love doing:

  case
  when song.name == 'Misty' ; puts 'Not again!'
  when song.duration > 120  ; puts 'Too long!'
  when Time.now.hour >  21  ; puts "It's too late"
  else
    song.play
  end
even more, for simple if/elses, many times I do:

  if member.coding_style.vertical_align?
  then friends

Re: The Ruby Style Guide

#36

Post by Demiurge »

danso wrote: post #6
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…

Funny, I've been wanting to do/working on a SQL style guide myself, with a big emphasis on using leading commas because of the readability and easy-adjustability. I do something like this: SELECT a, b FROM t1 LEFT OUTER JOIN t2 ON t2.t1_id = t1.id WHERE t2.c = 'foo' ;

This is also my preferred style. This means the keywords are separated from variables, and there is no code-based arbitrary space-alignment.

Re: The Ruby Style Guide

#37

Post by intsunny »

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.

Re: The Ruby Style Guide

#38

Post by matthewmacleod »

intsunny wrote: post #37

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.

I much prefer this, though I accept its not without problems in some cases. I find that say Javascript in comparison has a lot of syntactic noise; it's all annoyingly boiler-plate.

Maybe JS's implicit-return-in-arrow-functions is a better compromise.

Re: The Ruby Style Guide

#40

Post by taffer »

pswenson wrote: post #11

80 char line length in 2019?

There are many good reasons for that IMO:

* Too long lines are hard to read. For text 11 words per line are recommended, otherwise your eyes will loose track. 11 Words is roughly 60 characters, but code is indented so you need a bit more.

* Some people look at your code in an 80-column terminal, if you use more, this would be rude.

* Some people use a GUI diff tool that displays the code side by side, so that's already 160 characters.

Post reply on HN