Ruby Coding Standards

These are the guidelines for writing code for Camel Punch. Please ask for assistance if you have any questions: it’s easy to get hung up on testing especially.

Integration tests

Please use Cucumber for integration tests.

Steps should be written in a declarative style, and the imperative style should be avoided. i.e. put details into step definitions.

Where feasible, scenarios should be written in collaboration with the client.

Unit tests

Use RSpec for unit tests. You should aim for 100% code coverage.

Unit tests should not make calls to the database or network unless you are testing database logic e.g. ActiveRecord scopes (see Andrew Bruce’s blog for best practice for scope testing). You should always try to test only one method at a time, stubbing the results of calls to other methods.

Use FakeWeb with FakeWeb.allow_net_connect = false (or the WebMock equivalent - FakeWeb can interact badly with Selenium) to ensure no RSpec tests make calls to the network.

Unit tests are not required for Rails controllers so long as the controller is covered by a Cucumber feature. However, controller specs are encouraged where there is interesting controller logic.

Unit tests are required for all models and libraries. Changes are highly likely to be rejected if they are missing test coverage.

Indentation

Always use two space indent, not four spaces, not tabs.

Do not indent methods under the protected or private keywords any more than normal methods.

Blocks

Always use the do/end form for multiple line block. For inline blocks, always use the {} form.

Conditions

Never use single equals (assignment) in conditions, it is too easily confused with double equals.

This is bad:

if track = Track.find_by_name(name)
  track.update_attributes(params[:track])
end

It should be written like this:

track = Track.find_by_name(name)
if track
  track.update_attributes(params[:track])
end

Or, more concisely: