The Totally Unofficial Ruby coding style guide

<i>&#62; Prefer map over collect, find over detect, find_all over select, size over length. This is not a hard requirement, though - if the use of the alias enhances readability - it's ok to use it.</i><p>Not too sure about that... I prefer collect/detect/select/reject...<p><i>&#62; Keep existing comments up-to-date - no comment is better than an outdated comment.</i><p>Ambiguous sentence warning!

Although it's the naming pattern I've always used for constants (both in Java and Ruby code), I've never heard of it referred to as "SCREAMING_SNAKE_CASE". I like that.

I like the idea of an unofficial style guide on github - companies can fork &#38; edit, then new hires can diff against the version they're most familiar with.

This breaks once the first editor with proportional width font support becomes popular in Ruby land:<p><pre><code> kind = case year when 1850..1889 then "Blues" ... </code></pre> I also have a question that I have always wanted to ask. I am not a native speaker of English. Are "if not" and "unless" really the same thing?<p>Does this:<p><pre><code> def foo(x, y, z) destroy_universe unless all_arguments_valid? # more code... </code></pre> and this:<p><pre><code> def foo(x, y, z) destroy_universe if not all_arguments_valid? # more code... </code></pre> really have the same implications? "unless" makes it sound a tiny bit as if "all_arguments_valid?" was the exception - to me at least. Does anyone else use "if not" based on this gut feeling sometimes?

I'm clueless about ruby. Never learned it. But this makes me cringe (obviously I'm coming from a different context, but is this really a good idea? And who wants to have a table like this?) ..<p>&#62;The length of an identifier determines its scope. Use one-letter variables for short block/method parameters, according to this scheme:<p><pre><code> a,b,c: any object d: directory names e: elements of an Enumerable ex: rescued exceptions f: files and file names i,j: indexes k: the key part of a hash entry m: methods o: any object r: return values of short methods s: strings v: any value v: the value part of a hash entry x,y,z: numbers</code></pre>

I do not understand why the subclauses of `case` are not to be indented.

I am yet to hear anyone give a compelling argument in favour of parenthesising arguments to a method:<p><pre><code> def method_name(arg1, arg2) </code></pre> instead of<p><pre><code> def method_name arg1, arg2 </code></pre> especially when they do not like empty parentheses for no args<p><pre><code> def method_name() </code></pre> and they just love to omit the parentheses when actually using a method<p><pre><code> puts "odd" </code></pre> Why the inconsistency? Unnecessary parentheses are unnecessary! When in doubt .. let the args out!<p>edit:<p>&#62; Avoid hashes-as-optional-parameters. Does the method do too much?<p>And I'm totally against this. This is an extremely useful pattern and can be key to increasing readability. I basically insist on opts hashes on any method with more than 2 args. Wow, you can see what is intended rather than Model.do_something(3, false, false).<p>Any big application has methods that take a lot of switches. The opts hash pattern lets you at least label them, rather than rely on obscure argument order. And it lets you set defaults on the args in a sane way (rails' famous reverse_merge!). Why would anyone be against that?