Tip
Click on the linked pull request, commit, or the guideline itself to read more detailed explanations with examples and reasoning behind these recommendations.
- Use an opinionated set of rules for Rubocop
- Limit use of conditional modifiers to short, simple cases
- Avoid multiple assignments per line (
one, two = 1, 2). #109 - Avoid ternary operators (
boolean ? true : false). Use multi-lineifinstead to emphasize code branches. 36491dbb9 - Prefer nested class and module definitions over the shorthand version Example #332
- Prefer
detectoverfind. 0d819844 - Prefer
selectoverfind_all. 0d819844 - Prefer
mapovercollect. 0d819844 - Prefer
reduceoverinject. #237 - Prefer
&:method_nameto{ |item| item.method_name }for simple method calls. #183 - Use
%()for single-line strings containing double-quotes that require interpolation. 36491dbb9 - Use heredocs for multi-line strings. 36491dbb9
- Avoid monkey-patching.
- Generate necessary Bundler binstubs for the project, such as
rakeandrspec, and add them to version control. - Prefer classes to modules when designing functionality that is shared by multiple models.
- Avoid organizational comments (
# Validations). #63 - Use empty lines around multi-line blocks.
- Avoid bang (!) method names. Prefer descriptive names. #122
- Use
?suffix for predicate methods. 0d819844 - Use
def self.method, notclass << self. 40090e22 - Use
defwith parentheses when there are arguments. 36491dbb9 - Avoid optional parameters. Does the method do too much?
- Order class methods above instance methods. #320
- Prefer
privatewhen indicating scope. Useprotectedonly with comparison methods likedef ==(other),def <(other), anddef >(other).
- Prefix unused variables or parameters with underscore (
_). #335 - Name variables created by a factory after the factory (
user_factorycreatesuser). - Suffix variables holding a factory with
_factory(user_factory). - Use a leading underscore when defining instance variables for memoization. #373
- Prefer method invocation over instance variables. #331
- Specify the Ruby version to be used on the project in the
Gemfile. - Use a pessimistic version in the
Gemfilefor gems that follow semantic versioning, such asrspec,factory_bot, andcapybara. - Use a versionless
Gemfiledeclarations for gems that are safe to update often, such as pg, thin, and debugger. - Use an exact version in the
Gemfilefor fragile gems, such as Rails.
- Declare dependencies in the
<PROJECT_NAME>.gemspecfile. - Reference the
gemspecin theGemfile. - Use Appraisal to test the gem against multiple versions of gem dependencies (such as Rails in a Rails engine).
- Use Bundler to manage the gem's dependencies.
- Use continuous integration (CI) to show build status within the code review process and to test against multiple Ruby versions.
- Review the recommended practices outlined in Heroku's HTTP API Design Guide before designing a new API.
- Write integration tests for your API endpoints. When the primary consumer of the API is a JavaScript client maintained within the same code base as the provider of the API, write system specs. Otherwise write request specs.