

The Totally Unofficial Ruby coding style guide - bozhidar
https://github.com/bbatsov/ruby-style-guide

======
swombat
_> 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._

Not too sure about that... I prefer collect/detect/select/reject...

 _> Keep existing comments up-to-date - no comment is better than an outdated
comment._

Ambiguous sentence warning!

~~~
nakajima
Using #find in a Rails project tends to be a mistake, especially when used on
an ActiveRecord association proxy.

------
lylejohnson
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.

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

------
gurkendoktor
This breaks once the first editor with proportional width font support becomes
popular in Ruby land:

    
    
      kind = case year
             when 1850..1889 then "Blues"
             ...
    

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?

Does this:

    
    
      def foo(x, y, z)
        destroy_universe unless all_arguments_valid?
        # more code...
    

and this:

    
    
      def foo(x, y, z)
        destroy_universe if not all_arguments_valid?
        # more code...
    

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?

~~~
extension
As a native English speaker, I would say that "unless" _usually_ implies that
the condition is exceptional, which is why I try to avoid code like
"handle_error unless there_is_no_error".

------
darklajid
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?) ..

>The length of an identifier determines its scope. Use one-letter variables
for short block/method parameters, according to this scheme:

    
    
      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

~~~
jameskilton
I'm a heavy Ruby user and I've never seen or heard of this until now. The rest
of the document is pretty close to what I follow, but this one is theirs and
theirs alone.

~~~
nplusone
This Ruby style guide is based on
[https://github.com/chneukirchen/styleguide/blob/master/RUBY-...](https://github.com/chneukirchen/styleguide/blob/master/RUBY-
STYLE) , as stated in the introductory paragraph. That style guide also
contains these conventions for one-letter variable names.

Many others have forked this guide and made modifications according to their
tastes.

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

~~~
extension
For the same reason you don't indent 'else' relative to 'if'. It avoids
double-indentation and isn't really necessary. All of the lines under 'case'
will begin with one of 'when', 'else', or 'end' and are thus easy to spot
without indentation.

------
saturn
I am yet to hear anyone give a compelling argument in favour of parenthesising
arguments to a method:

    
    
      def method_name(arg1, arg2)
    

instead of

    
    
      def method_name arg1, arg2
    

especially when they do not like empty parentheses for no args

    
    
      def method_name()
    

and they just love to omit the parentheses when actually using a method

    
    
      puts "odd"
    

Why the inconsistency? Unnecessary parentheses are unnecessary! When in doubt
.. let the args out!

edit:

> Avoid hashes-as-optional-parameters. Does the method do too much?

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).

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?

~~~
bphogan
On the hashes part, it's tricky when reading the method itself what the
options are. For example, many of the Rails helper methods that take
html_options ={} are only documented in one place.

So it's cleaner from the side of invoking the method, but relies on the
developer of the method to heavily document what the hash's options are.
That's the only thing I've noticed.

