Github Ruby Styleguide

There was one thing with block chaining that I was really hoping they'd hit on. They didn't. They had:<p><pre><code> # good names.select { |name| name.start_with?("S") }.map { |name| name.upcase } </code></pre> I've noticed that sort of chaining is changing towards:<p><pre><code> names.select { |name| name.start_with?("S") } .map { |name| name.upcase } </code></pre> Which can be further chained (if need be) like so:<p><pre><code> names.select { |name| name.start_with?("S") } .map { |name| name.upcase } .sort .join(', ') </code></pre> Which, imo, is just better than trying to do it all on one line or using intermediate variables. It's more of a value call when it comes to the intermediate variables, though. I'd also use<p><pre><code> .map(&#38;:upcase) </code></pre> instead of<p><pre><code> .map { |word| word.upcase } </code></pre> But I think it's perfectly understandable if you find the word.upcase more explicit and readable.

I'm not a Ruby programmer, but a couple of these things just look completely wrong:<p># good<p>def some_method(some_arr)<p><pre><code> some_arr.size </code></pre> end<p>Omitting the return statement is a good thing? How do you know if this method even returns anything? .size could be a method that doesn't return anything, right, since parens are optional?<p>#good<p>do_something if something_else<p>This, to me, is horrible.<p>If you're just scanning down the file, you can easily miss the if statement, and assume the do_something always goes off.<p>Also, it's incredibly hard to process when I'm mentally executing the code in my head. Generally if there's a method call on the left, you just do it... but now we hit this if statement, ok, so mentally undo the method call we just processed, now check the if statement... now skip back to the do_something and reapply the method call... and now skip the if statement and continue on in the code.<p>...or you could just do if something_else then do_something (if you really must have single line if statements, which I am also against, but not so much as the if statement after the method it's controlling access to)

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 &#38;&#38; and || now for years and I haven't looked back. /PSA

I agree with almost everything except for using named groups over the $1-$9 variables in regular expression matching. This may be the case if there are many capture groups in the expression, but I would argue that<p><pre><code> /(?&#60;meaningful_var&#62;regexp)/ =~ string</code></pre> is a fair deal more difficult to read than simply<p><pre><code> /(regexp)/ =~ string</code></pre> Almost everybody familiar with PCRE will be familiar with the simpler form, and it's usually the case that the shorter the regular expression, the easier it is to understand and read.

I use pretty much the same style for my Ruby work. One thing I do differently is replacing<p><pre><code> %w(word1 word2 word3) </code></pre> with<p><pre><code> %w[word1 word2 word3] </code></pre> both result in<p><pre><code> ["word1", "word2", "word3"] </code></pre> 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?

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'm a little curious why<p><pre><code> %w(strings go here) </code></pre> is preferred to<p><pre><code> [strings, go, here] </code></pre> The first form requires extra work to escape spaces, the second form is a representation of an array everywhere in Ruby, including in the debugger and IRB.

I do not know of the single language, including the language of math, that gives equal precedence to their <i>and</i> and <i>or</i> operators. Sadly Ruby does, and it's a blight on the language. It's like giving equal precedence to + and \<i>. It's a choice, but not one that anyone would expect.<p>What's worse, Ruby give the "correct" relative precedence to &#38;&#38;/||. I suspect this inconsistency is the reason the OP cautions against using </i>and<i>/</i>or*. It's too bad because I miss the low precedence and/or operators (from perl) that can be used to avoid parenthesis that &#38;&#38;/|| would require in the presence of assignment, etc.

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.

Regarding "def self.method" vs. "class &#60;&#60; self; def method; end", one very big advantage of using the "class &#60;&#60; self" technique (which Github discourages) is that it allows grepping for "def method" to find the location of the method definition.<p>Perhaps my editor is old and featureless (and Ruby's dynamic nature doesn't help), but I grep for such things multiple times per day.

This makes me want to learn Ruby so bad. :(

Love it. Great read.

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.<p><i>The and and or keywords are banned. It's just not worth it. Always use &#38;&#38; and || instead.</i><p>If you find "and" and "or" not to be "worth it", it tells me that you don't understand the difference. The "&#38;&#38;" 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.<p><i>As you can see all the classes in a class hierarchy actually share one class variable.</i><p>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. :-)<p><i>edit: formatting</i>