This is an excerpt from our style guide for how we think about writing code
Our style and 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 Good: @rewards = Reward.all -
Bad: locals: {em_sett: email_settings} Good: locals: {email_settings: email_settings}
-
-
Avoid abbreviations or sacrificing shorter variable names for readability
-
Avoid object types in names (
user_array,email_methodCalculatorClass,ReportModule). -
Name variables, methods, and classes to reveal intent.
- 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.
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