1. 13

I’ve generally been in favor of using parenthesis for all method calls that are passed arguments in Ruby, with the argument that not using them makes it impossible to tell which methods are called in what order with what params in lines that chain multiple methods together. In this article, the author presents an argument that lines that require parenthesis to make it clear what’s happening are already bad, and the parenthesis just hide the badness. I’m not sure I agree, but I’m interested to see what the Ruby community here thinks of it.

  1.  

  2. 5

    (2013 – thought I’d read this before)

    The thing about optional parentheses is that it’s a noisier diff when you have to add them in after some change to your code means the interpreter won’t correctly parse without the parentheses anymore. That was what set my thinking on it and why I always use them in Ruby. (Except when there are no arguments, of course.)

    I can’t recall if I agreed with the notion that just using parentheses with nested methods-as-arguments makes it less ugly, but I definitely don’t now. However it does make the code scan-able, where my eyes would have to dart side-to-side a few times to figure out what the unmarked statement was doing. Easily read and obviously in need of polish is much better than difficult to read and possibly in need of polish, imho.

    1. 3

      For me parens are more about making my editing more efficient. (Any delimiter will do really, I just find indentation or white space delimiters egregious in practice)

      I absolutely love the parinfer plugin for example.

      1. 3

        After the first two years I used Ruby, I switched from only using parenthesis when I absolutely had to, to using them in almost all possible cases, with a list of four exceptions that would cause my code to feel very un-Ruby-like to most readers.

        These are the only situations where I consciously eschew parens:

        1. The idiomatic omission for puts.
        2. The idiomatic omission for arity 0 method calls.
        3. Singleton methods being used declaratively in a class definition (so-called “class macros”). This includes attr_reader and friends.
        4. The conditional clause of control flow keywords (if, case, elsif, unless). An exception is made when the clause is made of several boolean statements, possibly necessitating a line-break for readability, and for some reason I did not wrap that logic in its own distinctly-named method. Normally I do wrap it in a method and call that, which allows omitting parens and is often more readable anyway.

        Aside from these, I will always wrap arguments in parens. My reasoning is mostly in line with trevorbramble’s comment.

        1. 2

          I’d like to append to the “Generally favoring parens” argument, specifically the “it makes the code look like the other languages I’ve spent years learning to read”. In addition to this, it’s good not only for me but for:

          • My entire team (if it takes 2 weeks of unproductive time for a developer to learn/adjust, that adds up quickly over lots of developers)
          • Newcomers to the team, same argument as entire team
          • Outside contributors, same argument as entire team (oh hai open source)
          • People who might write multiple languages in a day (e.g. someone typically works with JS in the browser and needs to write some server code without having to worry about style)

          Of course, a counter argument here is that if anyone wants to write open source, the greater Ruby community doesn’t use parens (from what I’ve seen) so the developer would have to learn the style anyway (in a repo out of their control maybe with less tooling to help them out =/)