Ruby Best Practices

From Kolmisoft Wiki
Revision as of 13:06, 5 April 2013 by Admin (talk | contribs) (Created page with '==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 …')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

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.
  • 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'.

Good code example