Github Ruby Styleguide • Hacker News Board

Re: Github Ruby Styleguide

#51

Post by graywh » Wed, Dec 12, 2012, 5:05 PM UTC

onedognight wrote: post #49

I do not know of the single language, including the language of math, that gives equal precedence to their and and or operators. Sadly Ruby does, and it's a blight on the language. It's like giving equal precedence to + and \ . It's a choice, but not one that anyone would expect. What's worse, Ruby give the "correct" relative precedence to &&/||. I suspect this inconsistency is the reason the OP cautions against usin…

Ruby's and and or are for flow control like if and unless, not binary logic operators like (or synonyms for) && and ||.

Re: Github Ruby Styleguide

#52

Post by graywh » Wed, Dec 12, 2012, 5:10 PM UTC

kreeger wrote: post #11

I can't stress enough how important it is to _not_ use `and` and `or`. As a former die-hard fan of those operators, it bit me in the ass so hard when those didn't exactly work the way they were supposed to. I've been using && and || now for years and I haven't looked back. /PSA

Avdi Grimm gives a good explanation: http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/

Re: Github Ruby Styleguide

#53

Post by graywh » Wed, Dec 12, 2012, 5:16 PM UTC

lloeki wrote: post #37

philwelch wrote: post #19

Earlier quoted context omitted.

It's an imported Perlism, back from the days of the old assert idiom `foo == bar or die`. If `foo == bar` evaluates to true, the `or` is short-circuited, else it calls the built-in `die` function which kills the process.

More precisely && and || are meant to stand in boolean tests, whereas and and or are meant to tie expressions together DSL style, as an alternative to if/then, like so: @current_user.logged_in? or redirect_to login_path @current_user.can? :do_this or render :status => 403 shirt.blue? and return bar put_suit_on or put_pants_on

That's a good example

  shirt.blue? and return bar

would be equivalent to

  return bar if shirt.blue?

You can do the same with or and unless.

Re: Github Ruby Styleguide

#54

Post by yxhuvud » Wed, Dec 12, 2012, 5:49 PM UTC

jhund wrote: post #50

I use pretty much the same style for my Ruby work. One thing I do differently is replacing %w(word1 word2 word3) with %w[word1 word2 word3] both result in ["word1", "word2", "word3"] I prefer the bracket delimiters since they better indicate the array nature than the parens. In % notation you can choose your own delimiters, so why not use brackets?

Both are fine.

Just don't use linebreaks or weird utf8 characters, please.

EDIT: As delimeters. Feel free to use them inside the strings.

Re: Github Ruby Styleguide

#55

Post by yxhuvud » Wed, Dec 12, 2012, 5:52 PM UTC

danenania wrote: post #13

Agree nearly 100%, except I see no problem with omitting parentheses around arguments in method definitions. I've never had any trouble parsing this and it's a bit cleaner to my eye.

Agreed, unless the definition line spans multiple lines. Then ()'s are necessary for readability.

Re: Github Ruby Styleguide

#56

Post by sirclueless » Wed, Dec 12, 2012, 6:02 PM UTC

oinksoft wrote: post #47

Pewpewarrows wrote: post #39

Earlier quoted context omitted.

I agree. But in all code that I write, regardless of pretty much whatever language it's written in, I always explicitly add parentheses around what I want the order of operations to be. "1 * 3 + 4 / 20 && foo" is unreadable. No one wants to memorize the order of operations for every language they use and have to figure it out in their head. Make life easier for the people who have to maintain that line of code you ju…

For language-specific operators I could understand ... but to me, the cognitive load of the parentheses is worse than having to think for a moment about this particular set of operators which have the same precedence in every language I've used (and the arithmetic operators which I've had to know the order of since early grade school). Maybe I'll eat my foot some day, but (a == 1) && (b == 2) or (2 * 3) + 1 is nothin…

Those are both perfectly reasonable to me. There are in fact languages that would interpret your example #1 incorrectly, so if someone wants to disambiguate I have no qualms. Your example #2 is sort of braindead, but in a more complicated expression, where 2 3 or 1 were method calls or something, I would appreciate the parens.

Re: Github Ruby Styleguide

#57

Post by edwinnathaniel » Wed, Dec 12, 2012, 6:12 PM UTC

rauljara wrote: post #20

There was one thing with block chaining that I was really hoping they'd hit on. They didn't. They had: # good names.select { |name| name.start_with?("S") }.map { |name| name.upcase } I've noticed that sort of chaining is changing towards: names.select { |name| name.start_with?("S") } .map { |name| name.upcase } Which can be further chained (if need be) like so: names.select { |name| name.start_with?("S") } .map { |na…

Startin' to look like Java (with its fluent-interface pattern) :). Keep it up!

thumbs up

Re: Github Ruby Styleguide

#58

Post by Pewpewarrows » Wed, Dec 12, 2012, 6:23 PM UTC

oinksoft wrote: post #47

Pewpewarrows wrote: post #39

Earlier quoted context omitted.

I agree. But in all code that I write, regardless of pretty much whatever language it's written in, I always explicitly add parentheses around what I want the order of operations to be. "1 * 3 + 4 / 20 && foo" is unreadable. No one wants to memorize the order of operations for every language they use and have to figure it out in their head. Make life easier for the people who have to maintain that line of code you ju…

For language-specific operators I could understand ... but to me, the cognitive load of the parentheses is worse than having to think for a moment about this particular set of operators which have the same precedence in every language I've used (and the arithmetic operators which I've had to know the order of since early grade school). Maybe I'll eat my foot some day, but (a == 1) && (b == 2) or (2 * 3) + 1 is nothin…

There are plenty of things that you can leave out when writing parseable source code, but don't because it would make the code horribly un-readable.

That is, there's a reason for whitespace around operators, after commas, extraneous newlines, etc. It makes the code easier to read and maintain. Now while I'm willing to admit that this whole area is largely aesthetic and personal, if you submitted a line of code to me that was just this without the parentheses:

> 2 * 3 + 1

I would reject the code review in a heartbeat. Part of making your code readable to others and less error-prone during maintenance is adding extraneous stuff to it that isn't necessary for the code to parse/compile/interpret.

Re: Github Ruby Styleguide

#59

Post by sabat » Wed, Dec 12, 2012, 6:30 PM UTC

I like what I've read, but with a couple of cavaets. Ruby is the way it is on purpose. Discouraging people from using features of the language because the OP (presumably) does not understand how to use them: that's an anti-pattern.

The and and or keywords are banned. It's just not worth it. Always use && and || instead.

If you find "and" and "or" not to be "worth it", it tells me that you don't understand the difference. The "&&" and "||" versions bind more tightly, and that is not always desirable. Perl has the same set of constructs, and the Perl monks have been using them correctly for years.

As you can see all the classes in a class hierarchy actually share one class variable.

Well, yeah. That's meant to be a feature of the language, not "nasty behavior". It's good advice to use class instance variables, sure. But let's not imply that Ruby is a badly designed language; it's quite well-designed. This isn't Javascript. :-)

edit: formatting

Re: Github Ruby Styleguide

#60

Post by jordoh » Wed, Dec 12, 2012, 6:31 PM UTC

rauljara wrote: post #20

There was one thing with block chaining that I was really hoping they'd hit on. They didn't. They had: # good names.select { |name| name.start_with?("S") }.map { |name| name.upcase } I've noticed that sort of chaining is changing towards: names.select { |name| name.start_with?("S") } .map { |name| name.upcase } Which can be further chained (if need be) like so: names.select { |name| name.start_with?("S") } .map { |na…

This seems to be a popular style in javascript (particularly when using jQuery), but it's not actually valid ruby (edit: ruby 1.8.7, that is - see reply). The first line forms a valid statement, so the dots would need to be at the end of each line to indicate a line continuation. So it would need to be:

  names.select { |name| name.start_with?("S") }.
        map    { |name| name.upcase }.
        sort.
        join(', ')

Which is slightly more annoying in that you need to modify two lines to add a new chained line (the line you are adding and the dot added to the previous line).

This also creates a mild headache when refactoring, as any change to the length of the "names" variable would force you to re-align the entire chain. You could do something like:

  names.
    select { |name| name.start_with?("S") }.
    map    { |name| name.upcase }.
    sort.
    join(', ')