There’s a lot of value in having decisions made for you ahead of time. Nonetheless, decision fatigue is one of the things that annoyed me most about Rails after working in it for the first few years of my career; the flexibility and “expressiveness” of Ruby syntax makes it so writing code is a series of pointless decisions. Do I use parentheses in my function call? Do I use do/end or braces? Array indices or helper methods like .third? I’ve grown to question the value of this sort of thing. Rubyists used to say that various Ruby frameworks were DSL’s (DHH here restrains himself to saying it “looks like” a DSL) but frankly, leaving the parens off of method invocations isn’t a very convincing magic trick once you know how it works, and it’s not worth having to second guess whether to use parens every time you want to call a method.

…or you can use a standard formatter like standardrb and end that conversation entirely.

You’re right, it’s easy to bikeshed on which syntax constructs are more elegant, but the Ruby ecosystem provides tools to eliminate the need for that conversation.

> …or you can use a standard formatter like standardrb and end that conversation entirely.

This is the solution I've gravitated to in other languages (e.g. Black, gofmt), but that was after my time in the Ruby ecosystem.

While those decisions are completely meaningless as far as performance or correctness of your program goes, they do have value for readability. One way to deal with them is of course to install something like standardrb and never think about it. The other way is to read the code you just wrote, and see what reads clearer/better in a specific case.

> The other way is to read the code you just wrote, and see what reads clearer/better in a specific case.

Yes, that's the extra decision step in my main workflow loop that I'd like to cut out whenever possible.

I think in general it's almost impossible to cut out human consideration and still get auto-clarity. With an auto-formatter you gain a little speed and lose a little readability. I think most people are really arguing about whether this trade off is worth it. Some are arguing that any readability gains are minimal (and debatable), but then it's like arguing that there's no point to being a better writer, and information can just be auto-formatted for human consumption with a set of standard heuristics. I guess we might actually get this world once everything is written by ChatGPT to maximize consistency. But then, how can we both claim to like complete and total mechanical consistency in code, and dislike it in any other form of writing? If code can be written more than one way, shouldn't we optimize it the same way for fellow devs as good writers would for their readers?

To be blunt with you, I think Rubyists cling to optional parentheses for purely aesthetic reasons; all of the supposed Ruby “DSL’s” that are just method invocations without parentheses would be no less and arguably even more clear and readable with parentheses.

Frankly, parentheses was the last thing on my mind. I typically use them by default, and remove them in cases where it might make sense.

Mostly I was thinking about stuff like arrangements of hashes, arrays, method arguments, naming of methods and variables, various styles of method chaining, block usage, etc.

Sure, but that kind of stuff is not generally unique to Ruby.

That's interesting. I've had the opposite reaction to those many little decisions: it doesn't matter. Do whichever you like. All of the options are sufficiently readable.

It matters somewhat. I had a coworker who used to avoid parens any time it was possible which I found incredibly annoying:

  "foo bar"
    .split(" ")
    .map(&:capitalize)
    .join " "

There is really no advantage to not putting parens for the `join` call. Meanwhile, it makes modification a pain as well as makes for some ugly diffs.

But as a sibling comment mentioned: just use a linter.

the convention that i think most rubyists gravitate toward is to always include parens for method calls when calling something that takes a parameter. omit if there are no parameters.

Yes, definitely omit parentheses when calling a method without arguments.

For calls with some non-block arguments, it's not so clear-cut as "always include parentheses".

Some methods are so prevalent that they almost become part of the language "syntax", even though there's nothing syntactically special about them. For example, you rarely see parentheses used on calls to `attr_accessor` or `private`:

  class Cat
    attr_accessor :fluffiness
    
    private def plan_world_domination
      # TODO
    end
  end

I think parentheses around `private(def some_method ... end)` would be especially non-idiomatic. Even though passing the result of the `def` expression to the `private` method is exactly what's happening.

Another place where it's usual to omit method call parentheses is on embedded DSLs. For example, in RSpec it's uncommon to include parentheses on calls to `describe` or `it`.

  describe "RSpec DSL" do
    it "looks neater without parentheses" do
      # ...
    end
  end

yeah there will always be edge cases but those are few and why i hedged with gravitate toward. private feels like a part of the language actually like an if statement instead of a method though.

It is, and it's how I do it when I write Ruby. I was just responding to "it doesn't matter" part of the parent comment. If you decide not to use parens, then you get situations like the one I illustrated where you have to use parens for chaining then you're left with a decision about what to do with the last one.

Why are the parens important in this example?

You can't chain without parens.

  # Does not work
  "foo bar"
    .split " "
    .join " "

There was a proposal to introduce a "pipe" operator at one point which was shot down [0]. It wasn't actually a pipe operator at all and really just an operator that would have made the previous syntax possible (|>, instead of .)

[0] https://dev.to/baweaver/ruby-2-7-the-pipeline-operator-1b2d