CODEWITHSUNDEEP
rubystandardsconventions
user12212177
user12212177

Reputation:

Ruby - when I should use parenthesis or not when calling a function/method

Is there a clear standard or guide to use or not use parenthesis when calling a function/method?

For example, the following code:

class List < Jets::Stack
  sqs_queue(:dead_letter)
end

Should I or shouldn't I use parenthesis? Other example:

class ExampleJob < ApplicationJob
  def sqs_event ref(:dead_letter)
  end
end

vs.

class ExampleJob < ApplicationJob
  def sqs_event ref :dead_letter
  end
end

Is there a official guideline I can follow?

Upvotes: 2

Views: 4022

Answers (4)

Nick Roz
Nick Roz

Reputation: 4230

Yes there is

I suppose you are looking for community guidelines since there is not style guides from Ruby core team.

Well, whenever you call a method you should use parenthesis, otherwise it becomes unclear

# bad
x = Math.sin y
# good
x = Math.sin(y)

# bad
array.delete e
# good
array.delete(e)

# bad
temperance = Person.new 'Temperance', 30
# good
temperance = Person.new('Temperance', 30)

However it is recommended to skip them when there is no arguments.

Be careful with super and super() they are different. super without brackets passes all the parameters implicitly. super() with empty brackets omits all the parameters

The only exception that comes to my mind is some kind of custom DSL, there must be some rules or preferences for DSL itself e.g.

validates :name, presence: true

It is also true for methods with keyword arguments:

attr_reader :name, :age

Upvotes: 2

orde
orde

Reputation: 5273

According to Matz:

If arguments are given to a method, they are generally surrounded by parentheses,

object.method(arg1, arg2)

but they can be omitted if doing so does not cause ambiguity.

object.method arg1, arg2

Upvotes: 0

Michael Durrant
Michael Durrant

Reputation: 96464

In Ruby it is usually optional.

Ruby tends towards minimalism so they are often avoided.

Sometimes they are required such as in rspec expect where

expect a.to be true

has to be

expect(a).to be true

Using no parens or empty parens when calling a method that has a parameter results in ArgumentError unless you a default for the param, i.e.

def a(x=1)

The other consideration is when you want to call a method on the result of something, when you'll need want that method to clearly be on the final result, i.e.

"br" + "own".upcase 

brOWN

However

("br" + "own").upcase

BROWN

Finally, as I'm talking about clarity, sometimes it may be better to have them, even when not strictly needed. This is generally in compound expressions, rather than relying on operator precedence, etc. Or if you want an expression that specifically does not get executed by standard operator precedence and you want your own grouping and order of operations, for example:

irb(main):007:0> 5 + 6 * 2
=> 17
irb(main):008:0> (5 + 6) * 2
=> 22

As Nick indicated, the one complication is super where super or super() pass on parms but super(a,b) calls super with... a,b as params

Upvotes: 1

BobRodes
BobRodes

Reputation: 6165

There isn't an official standard for Ruby code best practices. However, a set of preferred styles has evolved in the Ruby community. It's a good idea to follow those preferred styles, just because it makes your code more easily readable by other Ruby programmers.

Nick Roz has given you a link to the style guide. I would also recommend that you consider installing and using rubocop. It will give you feedback on when and when not to parenthesize arguments, many other formatting matters such as proper indenting, and which of the often several different syntax options to choose in a particular situation.

To answer your specific question about whether or not to use parentheses for method arguments, the answer is yes, in general. Exceptions are, as the guide says, "methods that have 'keyword' status in Ruby." An example is puts (actually the Kernel.puts method). Most people don't use parentheses here, but the guide states that they are optional.

Another example, as Nick has said (although "methods with keyword arguments" isn't quite correct; in that case the arguments are symbols that represent methods rather than keywords), is attr_accessor, which is actually Module.attr_accessor.

So, as a general rule, if it looks like a "command" (a "keyword," if you will), but is actually a method, omit the parentheses. Otherwise, use them. And if you're not sure of the difference, get in the habit of using rubocop.

Upvotes: 3

Related Questions