To paren, or not to paren: that is the question:
Whether ’tis nobler in the mind to suffer
The bugs and errors of maintenance programs,
Or to take arms against a host of typos,
And by debugging end them? To hack: to slash;
No more; and by a slash to say we end
The heart-ache and the thousand natural shocks
Of cut and paste code, ’tis a maturation
Devoutly to be wished. To hack, not slash;
Not slash: perchance to code: ay, there’s the rub;
For in that new programme what code may come
When we have shuffled off this unix box,
Must give us pause: there’s the respect
That makes wuffy of so long life;
— Not William Shakespeare
There’s been a good deal of conversation of late on comp.lang.ruby as to whether or not to use parentheses. And when to use them. Ruby is such that parentheses are optional, except, of course, when they’re not. Here’s some examples of where they are not:
irb(main):002:0> "parenthesis".length()
=> 11
irb(main):003:0> "parenthesis".length
=> 11
...
irb(main):009:0> class Foo
irb(main):010:1> attr_accessor :bar, :groo
irb(main):011:1> attr_reader(:gruff)
irb(main):012:1> end
=> nil
irb(main):013:0> f=Foo.new
=> #
irb(main):014:0> f.gruff
=> nil
irb(main):015:0> f.bar
=> nil
Notice that Ruby also doesn’t care if you use parenthesis or not for the arguments; in this case it doesn’t matter whether or not the parenthesis are there, because the meaning is clear, at least to the compiler. And now, for something completely different, an instance where meaning is not clear to the compiler.
irb(main):016:0> class Foo
irb(main):017:1> def fud(thing)
irb(main):018:2> thing.reverse
irb(main):019:2> end
irb(main):020:1> end
=> nil
irb(main):021:0> f.fud "hi"
=> "ih"
irb(main):022:0> f.fud "hi" ? true : false
(irb):22: warning: string literal in condition
NoMethodError: undefined method `reverse' for true:TrueClass
from (irb):18:in `fud'
from (irb):22
from /usr2/jest/tools//lib/ruby/site_ruby/1.8/rubygems/dependency.rb:19
irb(main):023:0> f.fud("hi") ? true : false
=> true
In the first instance, it is trying to evaluate
"hi" ? true : false
and then pass it to f.fud. This doesn’t work very well, since true does not have a reverse method. We’re running into an issue of order of operation. However, when we do
f.fud("hi") ? true : false
then we are successful. “hi” can be reversed and the result can be checked for non-nil-ness. In this (admittedly simplistic) example, the parenthesis were needed in order to achieve a satisfactory result.
In terms of background, I learned C 20 years ago. I cut my teeth on basic back in 1980. So I’ve been around for a little while. I mention this because several posters mentioned that one’s preference for using parenthesis may depend on one’s background, with those who come from C potentially more likely to use parenthesis whether they were needed or not.
I am of the opinion that parenthesis can make the code harder to read.
attr_accessor :first, :last
has_many :pets
is easier to my eyes and far easier to read as it mimics “natural” language than
attr_accessor(:first, :last)
has_many(:pets)
However, I realize that it is a personal choice. So my rule of thumb is to not use parenthesis, except where there is a question of clarity. I think that writing clear, maintainable code is more important than adhering to a rule of always using parenthesis. I like that Ruby, like Unix, generally has more way than one to do a thing. I understand that there are people who prefer one way of doing a thing. For those people, there’s Python. I’m kidding, of course — you can adhere to doing things a single way, such as always using parenthesis, in Ruby. To me, however, it would lessen my enjoyment of the language. And I write code in Ruby because it makes me happy to do so.
So, what do you think? Is there a compelling reason to use parentheses?
