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

61–70 of 73 posts

Re: Github Ruby Styleguide

#61

Post by philwelch »

graywh wrote: post #53
lloeki wrote: post #37

Earlier quoted context omitted.

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 .

I find the postfix if and unless far more readable than the Perlish and and or operators. The "or die" construction for asserts is really amusing though.

Re: Github Ruby Styleguide

#62

Post by sabat »

look_lookatme wrote: post #25
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

Agreed. It's just not worth it, especially with implicit return.

They're not synonyms; "and" is not a more readable version of "&&".

As Avdi Grimm says: and and or, despite an apparent similarity to && and ||, have very different roles.

It's worth using "and" and "or", especially considering that && and || bind too tightly for some purposes. I try to avoid && and || unless I'm doing a specific boolean operation (e.g. x = foo || bar). Not for flow control, though.

If you really can't grok the logic, use parens.

Re: Github Ruby Styleguide

#63

Post by lucisferre »

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?

Lots of reasons to keep lines sort, though you could argue 80 is pushing it. I've found 100-120 is generally fine for most scenarios on modern hardware.

Just keep in mind that code will be read and shown in a variety of different places. For example reading the code on github or other source control tracking tools, reading it on different terminals with splits active (tmux and VIm splits), etc. Keeping it short just makes it more portable for readability purposes. That's definitely a good thing.

Re: Github Ruby Styleguide

#64

Post by lucisferre »

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.

I think the issue is around the ambiguity and cognitive friction associated with figuring out where you require them and where you don't. Generally speaking I don't have a lot of problems with it, but I could see why someone might just say "always" to this one.

Re: Github Ruby Styleguide

#65

Post by dpritchett »

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’ve learned a lot of programming languages over the years, and I’ve taken care never to learn the operator precedence rules in any of them. It’s easy to get them wrong and get bitten and why should I require that people reading my code learn those stupid rules.

- Tim Bray

[1] http://www.tbray.org/ongoing/When/201x/2010/06/29/No-Default...

Re: Github Ruby Styleguide

#66

Post by rauljara »

jordoh wrote: post #60
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…

> but it's not actually valid ruby.

You are correct that it is invalid for 1.8.6. The code runs just fine in 1.9, though. I take advantage of many things that don't work in 1.8.6, so I'm not particularly concerned with my method chaining breaking compatibility.

I prefer the more-than-2-spaces indentation because, by the shape of the code, it is clearer to me that this is a method chain and not a change in control structure. That is also obvious by actually reading the code, though, so I'm fine putting that down to personal preference.

Re: Github Ruby Styleguide

#67

Post by jordoh »

rauljara wrote: post #66
jordoh wrote: post #60

Earlier quoted context omitted.

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…

> but it's not actually valid ruby. You are correct that it is invalid for 1.8.6. The code runs just fine in 1.9, though. I take advantage of many things that don't work in 1.8.6, so I'm not particularly concerned with my method chaining breaking compatibility. I prefer the more-than-2-spaces indentation because, by the shape of the code, it is clearer to me that this is a method chain and not a change in control str…

Great to know about 1.9 - just looked through the 1.9 changelog and saw it described as "Newlines allowed before ternary colon operator (:) and method call dot operator (.)", so it does seem like they are encouraging this specific formatting style.

I agree that the fully indented code is much easier to visually parse - whether that outweighs the refactoring cost is certainly going to vary depending on the team (in addition to personal preference, as you mention).

Re: Github Ruby Styleguide

#68

Post by hamburglar »

xentronium wrote: post #7
lucian1900 wrote: post #4

Earlier quoted context omitted.

Returning the last expression is quite handy for a lot of functional patterns. One gets used to it very quickly, especially one has used lisp at all. Parens being optional is indeed a flaw in Ruby's design. Post-if can be handy, sometimes.

> Parens being optional is indeed a flaw in Ruby's design. This flaw allows us to have nice DSLs unencumbered with parens.

There may be such a thing as a "nice DSL" but the absurd proliferation of poorly-thought-out DSLs that results from ruby's syntax is really not a positive thing.

Ha ha, my cute gem makes it look like you're making static declarations in a domain-specific language, but what you're really creating is a bunch of code that executes at unpredictable times and in an order that's impossible to untangle! Good luck! On the upside, you can create a trivial example of [something] in four lines of code!

Re: Github Ruby Styleguide

#69

Post by bryanlarsen »

sabat wrote: post #59

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

Ruby is mostly well-designed, but it certainly has its warts. One of them is that 'or' and 'and' have the same precedence. They don't in Perl. That's one reason while Perl monks use them, but Ruby rockstars don't.

And please don't try to tell me that the lambda/proc/block mess is "well-designed".

Re: Github Ruby Styleguide

#70

Post by xentronium »

hamburglar wrote: post #68
xentronium wrote: post #7

Earlier quoted context omitted.

> Parens being optional is indeed a flaw in Ruby's design. This flaw allows us to have nice DSLs unencumbered with parens.

There may be such a thing as a "nice DSL" but the absurd proliferation of poorly-thought-out DSLs that results from ruby's syntax is really not a positive thing. Ha ha, my cute gem makes it look like you're making static declarations in a domain-specific language, but what you're really creating is a bunch of code that executes at unpredictable times and in an order that's impossible to untangle! Good luck! On the up…

Understandable concern, but nobody can force you to use the said gem, can they? Such fluff shouldn't be a big deal as long as it is not ingrained in most developers' minds.

Besides, it looks like ruby community is currently gravitating towards more javaesque style of programming, heavy on patterns like dependency injection, very explicit, with lots of classes and almost none metaprogramming.

Post reply on HN