Study Ruby Style Guides
I always think reading style guides is one of the fast ways to grasp the knowledge of a new language. Here are some snippets from various Ruby style guides:
Coding Style
- Indent
when
as deep ascase
.
- Align the parameters of a method call if they span more than one line.
- Add underscores to large numeric literals to improve their readability.
Naming
- Use
snake_case
for methods and variables. - Use
CamelCase
for classes and modules. (Keep acronyms like HTTP, RFC, XML uppercase.) - Use
SCREAMING_SNAKE_CASE
for other constants. - The names of predicate methods (methods that return a boolean value) should
end in a question mark. (i.e.
Array#empty?
). - The names of potentially “dangerous” methods (i.e. methods that modify self or
the arguments,
exit!
, etc.) should end with an exclamation mark. Bang methods should only exist if a non-bang method exists. (More on this).
Syntax
-
The
and
andor
keywords are banned. It’s just not worth it. Always use&&
and||
instead. -
Favor modifier
if/unless
usage when you have a single-line body.
- Never use
unless
withelse
. Rewrite these with the positive case first.
-
Avoid
return
where not required. -
Use
||=
freely to initialize variables. But not in initializing boolean variables.
- Never put a space between a method name and the opening parenthesis. If the first argument to a method begins with an open parenthesis, always use parentheses in the method invocation.
- Use _ for unused block parameters.
Classes, and Modules
- Avoid the usage of class (
@@
) variables due to their unusual behavior in inheritance.
- Avoid explicit use of
self
as the recipient of internal class or instance messages unless to specify a method shadowed by a variable.
- When defining binary operators, name the argument
other
(<<
and[]
are exceptions to the rule, since their semantics are different).
- Prefer modules to classes with only class methods. Classes should be used only when it makes sense to create instances out of them.
Collections
- Prefer
%w
to the literal array syntax when you need an array of strings.
- Use ranges or
Comparable#between?
instead of complex comparison logic when possible.
Strings
- Prefer string interpolation
"#{name} <#{email}>"
than string concatenationname + "<" + email + ">"
. - Prefer double-quoted strings. Interpolation and escaped characters will always work
without a delimiter change, and
'
is a lot more common than"
in string literals. - Avoid using
String#+
when you need to construct large data chunks. Instead, useString#<<
. Concatenation mutates the string instance in-place and is always faster thanString#+
, which creates a bunch of new string objects.
Regular Expressions
- Use non-capturing groups when you don’t use captured result of parentheses.
- Avoid using $1-9 as it can be hard to track what they contain. Named groups can be used instead.
- Be careful with
^
and$
as they match start/end of line, not string endings. If you want to match the whole string use:\A
and\Z
.
- Use
x
modifier for complex regexps. This makes them more readable and you can add some useful comments. Just be careful as spaces are ignored.
Lambda, Proc, and Block
- Prefer
{...}
overdo...end
for single-line blocks. Avoid using{...}
for multi-line blocks (multiline chaining is always ugly). Always usedo...end
for “control flow” and “method definitions” (e.g. in Rakefiles and certain DSLs). Avoiddo...end
when chaining.
- Use the new lambda literal syntax for single line body blocks.
Use the
lambda
method for multi-line blocks.
- Prefer
proc
overProc.new
.
- Prefer
proc.call()
overproc[]
orproc.()
for both lambdas and procs.
Exceptions
- Signal exceptions using the
fail
method. Useraise
only when catching an exception and re-raising it (here you’re not failing, but explicitly and purposefully raising an exception).
- Release external resources obtained by your program in an ensure block.
Comments, and Documentation
- Use
TODO
to note missing features or functionality that should be added at a later date. - Use
FIXME
to note broken code that needs to be fixed. - Use
OPTIMIZE
to note slow or inefficient code that may cause performance problems. - Use
HACK
to note code smells where questionable coding practices were used and should be refactored away. - Use
REVIEW
to note anything that should be looked at to confirm it is working as intended. - Follow TomDoc on documentation.