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

41–50 of 73 posts

Re: Github Ruby Styleguide

#41

Post by prawks »

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…

Agreed. I'm no rubyist, but it's not only much more readable, but functionally easier to manage in code. I can easily comment out one or more blocks or methods in the chain in this case if need be, for example. I'm surprised they advocate it on one line, actually.

Re: Github Ruby Styleguide

#42

Post by olgeni »

dsr12 wrote: post #35

Now-a-days we have computers which can show more than 80 characters at a time. "Keep lines fewer than 80 characters", Is this recommendation still valid?

> Now-a-days we have computers which can show more than 80 characters at a time

Of course we do. We also have serial ports that go way faster than 9600, so at last "ed" can be used to its full potential.

Re: Github Ruby Styleguide

#43

Post by prawks »

Pewpewarrows wrote: post #39
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

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…

I can't believe more people don't do this. It seems like such a no-brainer when I'm writing. Not only for others, but for myself as well.

Re: Github Ruby Styleguide

#44

Post by philwelch »

dsr12 wrote: post #35

Now-a-days we have computers which can show more than 80 characters at a time. "Keep lines fewer than 80 characters", Is this recommendation still valid?

I find 80 a bit cramped myself. There are a lot of lovely one-line idioms, like postfix if and iterator blocks, which feel constrained at 80 characters. Worse of all, I spend time worrying about line width.

In principle, having a line width limit is a worthwhile idea. 120 rarely gives me problems, and I can fit 240 characters wide in any case.

Re: Github Ruby Styleguide

#46

Post by [deleted] »

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…

[deleted]

Re: Github Ruby Styleguide

#47

Post by oinksoft »

Pewpewarrows wrote: post #39
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

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 nothing but code smell to me.

Re: Github Ruby Styleguide

#49

Post by onedognight »

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 using and/or*. It's too bad because I miss the low precedence and/or operators (from perl) that can be used to avoid parenthesis that &&/|| would require in the presence of assignment, etc.

Re: Github Ruby Styleguide

#50

Post by jhund »

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?
Post reply on HN