commenting restriction

Question

In ruby 1.9, conditions on where to end a line was relaxed, so that we can now start a line with a period showing a method call. This is convenient when we have chained and non-chained methods mixed up, and want to show where the next non-chained one starts. Without this new feature, the best we could do was probably to use indentation:

method1(args1).
  method2(args2).
  method3(args3)
method4(args4).
  method5(args5).
  method6(args6)

or insert a blank line. But this was inconvenient because we have to pay attention to the indentation, and at the same time, not forget to put a period after every method call but the last one in the chain. Because of this, I created so many bugs either having an extra or missing period. With the new feature, we can do it much nicer as:

method1(args1)
.method2(args2)
.method3(args3)
method4(args4)
.method5(args5)
.method6(args6)

where the period visually functions as indented bullets.

The problem is that, when you want to insert comments before a line starting with a period, it returns an error.

method1(args1)
# method2 does blah blah
.method2(args2)
# method3 then does foo foo
.method3(args3)
method4(args4)
# method5 does blah blah
.method5(args5)
# method6 then does bar bar
.method6(args6)

# => error

or

method1(args1)
 # method2 does blah blah
.method2(args2)
 # method3 then does foo foo
.method3(args3)
method4(args4)
 # method5 does blah blah
.method5(args5)
 # method6 then does bar bar
.method6(args6)

# => error

It seems that, "#...." is not simply dropped off, but is interacting with the code in some way. What is happening? What is the exact restriction here? When the periods were at the end of a line, this did not happen.

method1(args1).
  # method2 does blah blah
  method2(args2).
  # method3 then does foo foo
  method3(args3)
method4(args4).
  # method5 does blah blah
  method5(args5).
  # method6 then does bar bar
  method6(args6)

  # => no error

score 1 · Accepted Answer · answered Apr 17 '11 at 03:03

1

The lexical parser is probably "looser" in that it will ignore a single newline and whitespace immediately preceding a dot. It probably does not allow for multiple newlines. This splits chained statements up into an incoherent mess, and it becomes much more complicated to handle without false positives. That all said…

If you have to add inline comments, it's probably an inappropriate place for terse, chained statements.

answered Apr 17 '11 at 03:03

coreyward

77,547
20
137
166

I often have a chain of one-liners, each doing a particular task, and it makes sense to comment line-by-line. – sawa Apr 17 '11 at 03:31
And it's still against convention. You shouldn't have to comment one every line — the code should speak for itself. In cases where it doesn't some inline comments are helpful. Especially in regards to chaining, you can break those statements up into a list of calls and append very short line-ending comments on any that are unclear (if needed). Nobody wants to read a sentence-long comment and then the word-long code it belongs to. We get it. – coreyward Apr 17 '11 at 04:16
It's the other way around. The one-liner may have a block, or have a complicated regex. The comment can be simple phrases. In addition, I often test a few alternatives for a one-liner within the chains, and need to comment out the alternatives not under test – sawa Apr 17 '11 at 05:04

commenting restriction

1 Answers1