Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

Last active April 3, 2024 13:57
Show Gist options
  • Star 7 You must be signed in to star a gist
  • Fork 2 You must be signed in to fork a gist
  • Save stuartchaney/e7e7b86f6338ebd7f969e55dafe5080a to your computer and use it in GitHub Desktop.
Save stuartchaney/e7e7b86f6338ebd7f969e55dafe5080a to your computer and use it in GitHub Desktop.
Rivo Style

This is an excerpt from our style guide for how we think about writing code

General Guidelines

Our style and best practices 👇

Best Practices

  • We want to write Rails in a unified style to help keep things readable and easy to understand.
  • Strive for Rails best practices wherever possible.


  • Simple code == scalable and reliable code.
  • Write code as if you were writing English.
  • Name methods so anybody can understand what is happening.
  • These are not to be blindly followed; strive to understand these and ask when in doubt.


  • Our advantage in business is that we can move quickly against our larger competitors. Here's how this translates to engineering.
    • Focus on what matters in a task or building a feature. (80/20 pareto principle)
    • Don't get caught up in edge cases (Spending a full day on something only 1% of users will encounter)
    • Build the feature 80%-90%, then come back at a later time and address the other 10%.


  • Simplicity is a huge factor of how we strive to write code.
  • Keeping things simple is how we can scale confidently and have others enter the codebase and get up to speed as soon as possible.
  • KISS


  • Naming is a another big factor in how we like to write code.

  • Write as if you were writing English.

  • Avoid generic variable names

    • Bad:
      @info = Reward.all
      @rewards = Reward.all
    • Bad:
      locals: {em_sett: email_settings}
      locals: {email_settings: email_settings}
  • Avoid abbreviations or sacrificing shorter variable names for readability

  • Avoid object types in names (user_array, email_method CalculatorClass, ReportModule).

  • Name variables, methods, and classes to reveal intent.

Code Style and Standard

  • We follow and abide by the Standard gem.
  • There are no exceptions. This is exactly what the standard gem was built for. One source of truth that the community controls.
  • Check out this very short RailsConf video for more.

Formatting && Automated Code Review

Use Codacy to automatically review your GitHub pull requests for style guide violations, security issues and error prone code.

We apply standardrb rules using Rubocop inside of codacy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment