Ruby Best Practices

Programming

• Do not use "one-liners" (a lot of code doing many things in one line). This is valid for JavaScript also - if you are adding a minimized library version where all spaces are removed for performance reasons - remember to add a readable version also.

• Aggressively DRY code during development.

• Avoid abbreviations.

• Use comments.

• Avoid global variables.
• Avoid long parameter lists.
• Be consistent.
• Delete trailing whitespace.
• Don't duplicate the functionality of a built-in library.
• Don't over-design.
• Don't program defensively.

• Don't vertically align tokens on consecutive lines.
• Don't write more code than you need.
• Exceptions should be exceptional. Don't suppress them or use them for control flow.
• Guesses at future functionality should not be designed into the application.
• Keep methods small.
• Keep the code simple.
• Limit lines to a maximum of 80 characters.
• Do not commit unfinished functionality into main repository.
• Name variables, methods, and classes with intention-revealing names..
• Order variables and methods alphabetically when possible.
• Prefer single function exit points unless the complexity of the code is greatly reduced by multiple returns.
• Treat acronyms as words in names (XmlHttpRequest not XMLHTTPRequest), even if the acronym is the entire name (class Html not class HTML).
• Use 2 space indentation (no tabs) unless otherwise noted.
• Use an empty line between methods, blocks and conditionals.
• Use ASCII for variables, comments, method names, etc...
• Use only English in code and comments.
• Use default iterators for languages/types that support them.
• Use descriptive names that are both immediately obvious (to a new developer) and as short as possible without using abbreviations.
• Use implicit line joining where possible and indent continued lines.
• Use spaces around operators, after commas, colons and semicolons, around:

{ and before }

• Use Unix-style line endings (\n).

Ruby

• Avoid %q, %Q, %x, %s, and %W.
• Avoid conditional modifiers (lines that end with conditionals).
• Avoid hashes as optional parameters. Does the method do too much?
• Avoid meta-programming.
• Avoid monkey-patching core classes.
• Avoid return unless required.
• Avoid ternary operators (boolean ? true : false). Use multi-line if instead to emphasize code branches.
• Don't use unless with else.
• Prefer map over collect and reduce over inject due to symmetry and familarity with mapping and reducing in other technologies.
• Prefer detect over find and find_all over select to avoid confusion with ActiveRecord and keep select/rejectsymmetry.
• Use _ for unused block parameters. hash.map

{ \|_, v\| v + 1 }

• Use %() for single-line strings needing interpolation and double-quotes.
• Use %w() over , for an array of words.
• Use && and || for boolean expressions.
• Use ||= freely.
• Use

{...}
over do..end for single-line blocks.

• Use ! suffix for dangerous methods (modifies self).
• Use ? suffix for predicate methods (return a boolean).
• Use CamelCase for classes and modules, snake_case for variables and methods, SCREAMING_SNAKE_CASE for constants.
• Use def with parentheses when there are arguments.
• Use do..end over

{...}
for multi-line blocks.

• Use /(?:first|second)/ over /(first|second)/ when you don't need the captured group.
• Use def self.method over def Class.method or class << self.
• Use Set over Array for arrays with unique elements. The lookup is faster.
• Use single-quotes for strings unless variable interpolation is required.

Rails

• Consider extracting private methods to their own object.
• Don't invoke a model's class directly from a view.
• Don't use SQL or SQL fragments (where('inviter_id is not null')) outside of models.
• Use the default render 'partial' syntax over render :partial => 'partial'.