Ruby convention for chaining calls over multiple lines - ruby-on-rails

Question

What are the conventions for this?
I use the folowing style, but not sure it is the preferred one since if I miss a dot at the end I can run into a lot of issue without realising that.
query = reservations_scope.for_company(current_company).joins{property.development}.
group{property.development.id}.
group{property.development.name}.
group{property.number}.
group{created_at}.
group{price}.
group{reservation_path}.
group{company_id}.
group{user_id}.
group{fee_paid_date}.
group{contract_exchanged_date}.
group{deposit_paid_date}.
group{cancelled_date}.
select_with_reserving_agent_name_for(current_company, [
"developments.id as dev_id",
"developments.name as dev_name",
"properties.number as prop_number",
"reservations.created_at",
"reservations.price",
"reservations.fee_paid_date",
"reservations.contract_exchanged_date",
"reservations.deposit_paid_date",
"reservations.cancelled_date"
]).reorder("developments.name")
query.to_a # ....
So what are the conventions for chaining methods over multiple lines and which one should I prefer?
NOTE: I couldn't find a good example from the Ruby coding style guide.

Answer 1

There is actually a section on that in the Ruby style guide:
Adopt a consistent multi-line method chaining style. There are two
popular styles in the Ruby community, both of which are considered
good - leading . (Option A) and trailing . (Option B).
(Option A) When continuing a chained method invocation on
another line keep the . on the second line.
# bad - need to consult first line to understand second line
one.two.three.
four
# good - it's immediately clear what's going on the second line
one.two.three
.four
(Option B) When continuing a chained method invocation on another line,
include the . on the first line to indicate that the
expression continues.
# bad - need to read ahead to the second line to know that the chain continues
one.two.three
.four
# good - it's immediately clear that the expression continues beyond the first line
one.two.three.
four
A discussion on the merits of both alternative styles can be found
here.

Answer 2

In Ruby 1.9+ it's possible to write like this:
query = reservations_scope
.for_company(current_company)
.joins{property.development}
.group{property.development.id}
.group{property.development.name}
.group{property.number}
.group{created_at}
.group{price}
.group{reservation_path}
.group{company_id}
.group{user_id}
Much more readable, I think.

Answer 3

Here is a complete list of pros and cons of four options. Two of the options have not been mentioned in any other answer.
Pros and cons can be broken into unique ones and shared ones. Shared pros are the inverses of a unique con of another option. Similarly, shared cons are the inverses of a unique pro of another option. There are also some points that are pros for two options and cons for the other two.
To avoid repeating explanations, I describe each option’s shared pros and cons with just a summary of that point. Full details about a shared pro or con are available in the description of their inverse con or pro in another option’s unique section. For the points that are pros of two options and cons of the other two, I arbitrarily chose to put the full explanations in the set that starts with “. at line beginning”.
For a shorter list that leaves the shared pros and cons implicit instead of repeating them, see this old version of this answer.
. at line end
items.get.lazy.
take(10).
force
Pros
Shared with only one other option:
Continuing lines can be commented out freely, and comments can be added between lines
Pastable into IRB/Pry
Supported in Ruby 1.8
Shared with two other options:
When you read the initial line, it is clear that the expression continues
Plenty of horizontal space for continuing lines
Doesn’t require manual alignment of characters into columns
Looks fine when viewed in a proportional font
Has a minimum of punctuation, reducing typing and visual noise
Cons
Unique:
Continuing lines look strange on their own. You must read the preceding line to understand that they are a continuation.
Indentation is not a reliable indicator that a line continues from the previous line – it could merely mean the start of a block.
Shared with only one other option:
When editing the code, it is harder to comment out or reorder the last line
. at line beginning
items.get.lazy
.take(10)
.force
Pros
Shared with only one other option:
When editing the code, it is easier to comment out or change the order of the last line – no need to delete and add . or \.
Shared with two other options:
Continuing lines can be understood when seen on their own
Plenty of horizontal space for continuing lines
Doesn’t require manual alignment of characters into columns
Looks fine when viewed in a proportional font
Has a minimum of punctuation, reducing typing and visual noise
Cons
Unique:
When you read the initial line, it’s not immediately clear that the expression continues
If you use this in your codebase, then when you read a line, you must always check the line after to make sure that it doesn’t affect the initial line’s meaning.
Shared with only one other option:
The code silently breaks if you # comment out a continuing line, or add a comment between lines
You can’t paste this code into IRB/Pry without it being misinterpreted
Not supported in Ruby 1.8 and below
. at line beginning, indented to the previous .
items.get.lazy
.take(10)
.force
Pros
Shared with only one other option:
When editing the code, it is easier to comment out or change the order of the last line – no need to delete and add . or \.
Shared with two other options:
When you read the initial line, it is clear that the expression continues
Continuing lines can be understood when seen on their own
Has a minimum of punctuation, reducing typing and visual noise
Cons
Unique:
Each line’s code must fit into less horizontal space
Requires manual alignment of the .s into columns
It is easier if you have an editor plugin for aligning text, but still more work than using default indentation rules.
Even if your editing setup includes a plugin for alignment, your coworkers’ setups may not.
The code will look misaligned when viewed in a proportional font
Shared with only one other option:
The code silently breaks if you # comment out a continuing line, or add a comment between lines
You can’t paste this code into IRB/Pry without it being misinterpreted
Not supported in Ruby 1.8 and below
Shared with two other options:
When editing the code, it is harder to comment out or reorder the last line
\ at line end, . at next line’s beginning
items.get.lazy \
.take(10) \
.force
Pros
Shared with only one other option:
Continuing lines can be commented out freely, and comments can be added between lines
Pastable into IRB/Pry
Supported in Ruby 1.8
Shared with two other options:
When you read the initial line, it is clear that the expression continues
Continuing lines can be understood when seen on their own
Plenty of horizontal space for continuing lines
Doesn’t require manual alignment of characters into columns
Looks fine when viewed in a proportional font
Cons
Unique:
Requires more typing
Creates more visual noise
Shared with only one other option:
When editing the code, it is harder to comment out or reorder the last line

Answer 4

The reason why I choose the dot in the end of the line is that it will allow you to paste code in an IRB session. Also, you can't comment lines in the middle of the multi-line code if you use the dots in the beginning of the lines. Here's a good discussion to read: https://github.com/bbatsov/ruby-style-guide/pull/176