SHARE
TWEET

Untitled

a guest Oct 22nd, 2011 842 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. = Dan Kubb's Ruby Style Guide
  2.  
  3. You may not like all rules presented here, but they work very well for
  4. me and have helped producing high quality code. Everyone is free to
  5. code however they want, write and follow their own style guides, but
  6. when you contribute to my code, please follow these rules:
  7.  
  8.  
  9. == Formatting:
  10.  
  11. * Use ASCII (or UTF-8, if you have to).
  12.  
  13. * Use 2 space indent, no tabs.
  14.  
  15. * Use Unix-style line endings.
  16.  
  17. * Use spaces around operators, after commas, colons and semicolons,
  18.   around { and before }.
  19.  
  20. * No spaces after (, [ and before ], ).
  21.  
  22. * Indent `when` two spaces deeper than `case`.
  23.  
  24. * Use an empty line before the return value of a method (unless it
  25.   only has one line), and an empty line between defs.
  26.  
  27. * Use YARD and its conventions for API documentation. Don't put an
  28.   empty line between the comment block and the def.
  29.  
  30. * Use empty lines to break up a long method into logical paragraphs.
  31.  
  32. * Keep lines fewer than 80 characters.
  33.  
  34. * Strip trailing whitespace.
  35.  
  36.  
  37. == Syntax:
  38.  
  39. * Use def with parentheses when there are arguments.
  40.  
  41. * Never use for, unless you exactly know why.
  42.  
  43. * Never use then, except in case statements.
  44.  
  45. * Use when x then ... for one-line cases.
  46.  
  47. * Use &&/|| for boolean expressions, and/or for control flow. (Rule
  48.   of thumb: If you have to use outer parentheses, you are using the
  49.   wrong operators.)
  50.  
  51. * Avoid multiline ?:, use if.
  52.  
  53. * Use parentheses when calling methods with arguments.
  54.  
  55. * Use {...} when defining blocks on one line. Use do...end for multiline
  56.   blocks.
  57.  
  58. * Avoid return where not required.
  59.  
  60. * Avoid line continuation (\) where not required.
  61.  
  62. * Use ||= freely.
  63.  
  64. * Use OO regexps, and avoid =~ $0-9, $~, $` and $' when possible.
  65.  
  66.  
  67. == Naming:
  68.  
  69. * Use snake_case for methods.
  70.  
  71. * Use CamelCase for classes and modules. (Keep acronyms like HTTP,
  72.   RFC, XML uppercase.)
  73.  
  74. * Use SCREAMING_SNAKE_CASE for other constants.
  75.  
  76. * Do not use single letter variable names. Avoid uncommunicative names.
  77.  
  78. * Use consistent variable names. Try to keep the variable names close
  79.   to the object class name.
  80.  
  81. * Use names prefixed with _ for unused variables.
  82.  
  83. * Do not use inject in library code. In app code it is ok.
  84.  
  85. * When defining binary operators, name the argument "other".
  86.  
  87. * Prefer map over collect, detect over find, select over find_all.
  88.  
  89.  
  90. == Comments:
  91.  
  92. * Comments longer than a word are capitalized and use punctuation.
  93.   Use one space after periods.
  94.  
  95. * Avoid superfluous comments.
  96.  
  97.  
  98. == The rest:
  99.  
  100. * Avoid hashes-as-optional-parameters. Does the method do too much?
  101.  
  102. * Avoid long methods.
  103.  
  104. * Avoid long parameter lists.
  105.  
  106. * Use def self.method to define singleton methods.
  107.  
  108. * Add "global" methods to Kernel (if you have to) and make them private.
  109.  
  110. * Avoid alias when alias_method will do.
  111.  
  112. * Always freeze objects assigned to constants.
  113.  
  114. * Use OptionParser for parsing complex command line options and
  115.   ruby -s for trivial command line options.
  116.  
  117. * Write for 1.9, but avoid doing things you know that will break in 1.8.
  118.  
  119. * Avoid needless metaprogramming.
  120.  
  121. * Only give a method one purpose for existing. If you pass in a boolean
  122.   to a method, what you're saying is that this method has two different
  123.   behaviours. Just split it into two single purpose methods. If you have
  124.   to use the words "AND" or "OR" to describe what the method does it
  125.   probably does too much.
  126.  
  127. * If sections of a method are logically separate by blank lines, then
  128.   that's probably a sign that those sections should be split into separate
  129.   methods.
  130.  
  131. * Try to keep methods at no more than 10 lines long, and preferably
  132.   5 or less.
  133.  
  134. == General:
  135.  
  136. * Code in a functional way, avoid mutation when it makes sense.
  137.  
  138. * Try to have methods either return the state of the object and have
  139.   no side effects, or return self and have side effects. This is
  140.   otherwise known as Command-query separation (CQS):
  141.  
  142.     http://en.wikipedia.org/wiki/Command-query_separation
  143.  
  144. * Do not mutate arguments unless that is the purpose of the method.
  145.  
  146. * Do not mess around in core classes when writing libraries.
  147.  
  148. * Do not program defensively.
  149.   (See http://www.erlang.se/doc/programming_rules.shtml#HDR11.)
  150.  
  151. * Keep the code simple.
  152.  
  153. * Don't overdesign.
  154.  
  155. * Don't underdesign.
  156.  
  157. * Avoid bugs.
  158.  
  159. * Read other style guides and apply the parts that don't dissent with
  160.   this list.
  161.  
  162. * Be consistent.
  163.  
  164. * Use common sense.
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
Top