3

Why does Rubocop / the community-driven Ruby style guide recommend parentheses in method definitions?

def my_method(param1, param2)
end
# instead of
def my_method param1, param2
end

Method calls are allowed with or without parentheses depending on the situation. However, my first impression is that lack of parentheses in method calls are much more potentially ambiguous than lack of parentheses in method definitions. Was there a reason behind it, e.g. to make code more fool-proof, or did it happen because of "historical reasons" or "because it was the most widespread style"?

Clarification:

I am not asking for opinions about which style is easier to read.

The lint Lint/AmbiguousOperator is based on the idea that do_something *some_array is ambiguous and a source for bugs (Link). I wondered if this is the same case for Style/MethodDefParentheses (Link).

After going back to find the actual names of those Cops, my best guess right now is that there is no "technical" reason, but rather one is a proper "lint" and the other a "style" matter.

jleeothon
  • 2,907
  • 4
  • 19
  • 35
  • Doesn't it simply _read_ better? – Sergio Tulentsev Feb 06 '18 at 20:06
  • @SergioTulentsev That can be argued to be a matter of taste / tradition. That's why I ask if there are further reasons e.g. syntactical ambiguity. Ambiguity happens e.g. with the splat operator and multiplication e.g. `a *b` looks like both `a(*b)` and `a() * b()`; we would avoid `a *b` because it is more objectively a potential source for bugs. I don't see (yet) that being the case for methods in method declarations. – jleeothon Feb 06 '18 at 20:36
  • 2
    I'd estimate 90+% of ruby style guide to be based on nothing else than taste. ¯\\_(ツ)_/¯ Hence the name, "style guide". Its purpose is to encourage community to write code in the similar style. You can join a project and start reading the code, without getting used to this project's idiosynratic coding conventions. – Sergio Tulentsev Feb 06 '18 at 21:07
  • 1
    And no, off the top of my head, I too can't name a technical reason to prefer parenthesized method definitions. – Sergio Tulentsev Feb 06 '18 at 21:09
  • There are two votes to close the question. It's not because it's a bad question, just that it calls for an opinion, which is verboden for SO questions. – Cary Swoveland Feb 07 '18 at 02:23
  • 2
    There's really no way of knowing that I know of. That particular guideline appears to have been included with the initial commit of the README in the style guide repository: https://github.com/bbatsov/ruby-style-guide/commit/dc31232fe357d08039fb59a66199b189cd7aa605#diff-04c6e90faac2675aa89e2176d2eec7d8R73 which actually seems to be based off of this other style guide: https://github.com/chneukirchen/styleguide/commit/9057d68f2234f164342b4fc23a48f5b3a31c8ffe#diff-70fa10fe169bac53cdb85e5c7723433bR37 – dinjas Feb 07 '18 at 06:29
  • @CarySwoveland I would contest that. I'm not asking for opinions on what's nicer, but rather, I'm asking _whether or not_ there are technical reasons to prefer one style. If not, then the answer would be "no, it was a matter of style". Changed to question for clarification. – jleeothon Feb 07 '18 at 10:34
  • 1
    I just wanted you to know that the two members who voted to close may believe that the use of parentheses is only a stylistic issue, in which case an opinion is called for. I'm not saying that's my view. I am interested in the question, however. – Cary Swoveland Feb 07 '18 at 19:20

1 Answers1

3

The rationale is omitted in the initial commit, of which this rule was part, indicating that there was no particular technical reason for it.

The fact that the corresponding cop is placed in the Style department, rather than Lint, serves as further proof that this is a matter of just that, style.

Method definitions have a very simple syntax. The def keyword is (optionally) followed by arguments, which must be followed by a terminator (newline or ;).

The possible variations are:

  • single line method definitions,
  • inline modifiers, e.g. private,
  • default- and keyword arguments,
  • splat- and block arguments.

All of these work fine both with and without parentheses. Furthermore, running a file with an unparenthesized method definition using the -w flag raises no warnings.

These factors together rule out the possibility that the parentheses are recommended to avoid ambiguity.

Drenmi
  • 8,492
  • 4
  • 42
  • 51