Ruby on Rails Code Quality Checklist
By Evgeniy Kuzminykh, August 25th, 2009
- Each controller action only calls one model method other than an initial find or new. (Make custom .new or .update methods in the model with all necessary)
- Only one or two instance variables are shared between each controller and view.
- All model and variable names are both immediately obvious (to a new developer) and as short as possible without using abbreviations.
- All custom “finds” accessed from more than one place in the code use named_scope instead of a custom method.
- A .find or .find_by_ is never called in a view or view helper.
- There is zero custom code that duplicates functionality of a built-in function in rails.
- Code has been aggressively DRYed during development.
- All functionality used in two or more models has been turned into a library/module.
- All logic duplicated between two or more apps has been turned into a gemified plugin.
- STI is not used anywhere.
- Every design choice should yield the most simplistic design possible for the need of users at the current time. No guesses for future functionality were designed into the application.
- Close to full test coverage exists at the highest level of the application: on and between controller actions. Coverage is highest for code used by the most number of end users.
- All tests pass before code is merged into a shared repository.
- Every fixed defect on a deployed product has tests added to prevent regression.
- Every plugin installed has been code reviewed.
Thanks!
No STI?
Let’s not use any “if” statements, either — too much like a ‘goto’.
STI has a purpose, especially in an object-oriented design.
STI is a great technique but usually it adds more problems than it solves: empty columns in the DB, table fills very fast. Having similar functionality in the modules is much better.
Actually can’t images a situation where STI will be needed. And you? Can you please provide an example?