In Ruby, how do you split a long method chain across lines so it stays one expression, and where does a block attach?

## When a newline ends an expression Ruby treats a newline as the end of a statement **when the line is already a complete expression**. A line that is visibly unfinished, ending in `+`, `,`, `=` or `.`, continues onto the next one. That is why this is two statements, not one chain: ```ruby titles.map(&:strip) # complete: a statement on its own reject(&:empty?) # a separate call on self, not on the mapped Array ``` The second line calls `reject` on `self`, which usually raises `NoMethodError` or, worse, calls some unrelated method. ## Two layouts that keep a chain together | Style | Looks like | Why it parses | |---|---|---| | Trailing dot | `titles.` at line end, `map(&:strip).` next | the line ends with `.` and is incomplete | | Leading dot | `titles` then `.map(&:strip)` on the next line | a line starting with `.` continues the previous expression | | Backslash | `titles \` then `.map(&:strip)` | `\` explicitly joins the lines at parse time | - The **leading dot** is the common style: every step starts on its own line and can be read, reordered or commented out individually. It is the default of RuboCop's `Layout/DotPosition` cop (`EnforcedStyle: leading`), and `Layout/MultilineMethodCallIndentation` checks how the continued lines are indented. - Since **Ruby 2.7**, **comment lines** may sit between leading-dot lines, so a step can be annotated or disabled with `#`. - After a backslash no comment line is allowed, because the backslash is a parse-time line-break escape: the very next physical line must be the continuation. - **Ruby 4.0** extends the leading-line rule to logical operators: a line starting with `&&`, `||`, `and` or `or` now continues the previous line, just as a leading dot does. ```ruby display_titles = raw_titles .map(&:strip) # drop blank rows from the CSV import .reject(&:empty?) .map { |t| t.squeeze(" ") } .first(20) ``` ## Where a block goes in a chain A block is not a separate link: it is part of **one** method call, and it belongs to the call written immediately before it. 1. In `titles.map { |t| t.strip }.join(", ")`, the block is `map`'s; `join` then runs on the Array `map` returned. 2. To give a block to an earlier link, write it on that link: `titles.select { |t| t.size > 3 }.map(&:upcase)`. 3. The chain may continue after the closing `}` or `end`: `.map { ... }.join(", ")` or `end.join(", ")`. Chaining onto a multi-line `do...end` block, as in `end.map do ... end`, is legal but hard to scan. RuboCop's `Style/MultilineBlockChain` flags chaining a block after another block that spans multiple lines and suggests naming the intermediate result instead. How `{}` and `do...end` differ when a call's parentheses are omitted is a separate precedence question about blocks. ## Common mistakes - Adding a comment after a backslash continuation, which breaks the join because the backslash needs the continuation on the very next line. - Mixing leading and trailing dots in one chain, which linters reject and readers misread. - Assuming a block written at the end of a long chain applies to the first call. ## Choosing where to break A chain does not have to be split at every dot. A practical rule is to keep short, obvious steps together and give each **meaningful transformation** its own line: - Break before each step a reader should see as a separate stage: cleaning, filtering, formatting, limiting. - Keep a step with its block on one line when the block is short, `.map { |t| t.squeeze(" ") }`; switch to a named local when the block needs several lines. - Put the receiver on the first line alone when the chain is long, so every following line starts with a dot and aligns. - When a step needs an explanation, use a comment line between links rather than a trailing comment after the code.