Cop idea: prefer no parentheses: expect(subject).to eq(true) not expect(subject).to(eq(true))

[hubertjakubiak]

Idea for cop suggestion:

Prefer expect(subject).to eq(true) not expect(subject).to(eq(true)). The same when not_to so expect(subject).not_to eq(true) not expect(subject).not_to(eq(true)).

There's no single example where second approach is being used in https://github.com/rubocop-hq/rspec-style-guide.

[pirj]

Great idea.

There's this in the Ruby Style Guide:

Always omit parentheses for Methods that are part of an internal DSL (e.g., Rake, Rails, RSpec): validates :name, presence: true

Maybe add a cop here, and eventually a generic part if it to RuboCop, so that rubocop-rails could benefit from it as well, by marking validates and other Rails-specific DSL methods as such to be avoided.

Can't think of legit exceptions to this rule, e.g. when parenthesis would make sense.

[dgollahon]

Can't think of legit exceptions to this rule, e.g. when parenthesis would make sense.

We just have to be careful of to in other contexts, notably the second to with this change matcher

expect { man.you_cant_handle_the_truth! }.to change { man.the_truth? }.from(true).to(false)

[hubertjakubiak]

I actually fixed that with below custom config:

Style/MethodCallWithArgsParentheses:
  Enabled: true
  IgnoredMethods:
    # long list of other methods that are also better without parentheses
    - to
    - not_to