A guide for programming well.
- Don't duplicate the functionality of a built-in library.
- Don't swallow exceptions or "fail silently."
- Don't write code that guesses at future functionality.
- Exceptions should be exceptional.
- Keep the code simple.
- Avoid global variables.
- Avoid long parameter lists.
- Limit collaborators of an object (entities an object depends on).
- Limit an object's dependencies (entities that depend on an object).
- Prefer composition over inheritance.
- Prefer small methods. One line is best.
- Prefer small objects with a single, well-defined responsibility.
- Tell, don't ask.
- Avoid optional parameters. Does the method do too much?
- Avoid monkey-patching.
- Prefer classes to modules when designing functionality that is shared by multiple models.
privatewhen indicating scope. Use
protected' only with comparison methods likedef ==(other)
, anddef >(other)`.
- Don't change a migration after it has been merged into master if the desired change can be solved with another migration.
- Validate the associated
user), not the database column (
- Avoid multicolumn indexes in Postgres. It combines multiple indexes efficiently. Optimize later with a compound index if needed.
- Consider a partial index for queries on booleans.
- Constrain most columns as
- Store IDs, not
ActiveRecordobjects for cleaner serialization, then re-find the
ActiveRecordobject in the
- Disable real HTTP requests to external services with
- Test background jobs with a
- Use a Fake to stub requests to external services.
- Use integration tests to execute the entire app.
- Use non-SUT methods in expectations when possible.
- Don't support IE6.