Prefer {...} over do...end for multi-line chained blocks.
We use the enforced style braces_for_chaining
.
For example:
array_of_things.each do |thing|
thing if thing.condition?
end.compact
array_of_things.each { |thing|
thing if thing.condition?
}.compact
If we use Timeout.timeout
without a custom exception, rescue blocks may be prevented from executing.
For example:
Timeout.timeout(run_timeout)
Timeout.timeout(run_timeout, SomeModule::SomeError)
We explictly enabled the Rails/OutputSafety
cop to ensure its usage. It prevents usage of raw
, html_safe
, or safe_concat
unless they are explicitly disabled.
This blog post explains our feelings on unsafe HTML rendering.
We enforce usage of parentheses for all percent literal delimeters besides %r
(the macro for regexps) for which we use curly braces.
%w(one two three)
%i(one two three)
%r{(\w+)-(\d+)}
%w[one two three]
%i[one two three]
%w!one two three!
%r((\w+)-(\d+))
We enforce the style "snake_case", which means that we prefer to name variables that end in a number with an extra underscore.
user_1 = User.first
user_2 = User.second
user1 = User.first
user2 = User.second
The snake case style is more readable.
In RSpec tests, we prevent HTTP response status assertions against server error codes (e.g., 500). While it’s acceptable to “under-build” APIs under assumption of controlled and well-behaving clients, these exceptions should be treated as undefined behavior and thus do not need request spec coverage. In cases where the server must communicate an expected failure to the client, an appropriate semantic status code must be used (e.g., 403, 422, etc.).
expect(response).to have_http_status :forbidden
expect(response).to have_http_status 422
expect(response).to have_http_status :internal_server_error
expect(response).to have_http_status 500