Most Ruby on Rails beginners get excited by the framework and start crafting applications without any knowledge of the language. And there’s nothing wrong about it. At least, unless those beginners persist in such approach and become senior developers without any knowledge of the language.
Anyway, sooner or later, beginners or experienced programmers, we all run into so-called Ruby Gotchas – those small subtleties that hide from our sight for hours of hardcore debugging (logger.debug "*** #{object} ****") and then we go Ohh..That was that??! Really, this time I WILL read that book with a hammer on the cover! Or, rather, we go shit! and fall asleep.
Here is a list of popular Ruby gotchas and curiosities that developers should be aware of. For each case, there’s an example of confusing and/or error-prone code.
and / or
is NOT the same as && / ||
surprise = true and false # => surprise is true surprise = true && false # => surprise is false
Good practice
Use only
&& / ||
operators.In detail
and / or
operators have lower precedence than&& / ||
and / or
have lower precedence than=
assignment operator, while&& / ||
are of higher precedenceand
andor
have the same precedence, while&&
has higher precedence than||
and`
differs from `&&`
:(surprise = true) and false # => surprise is true surprise = (true && false) # => surprise is false
Some say: use and / or
for flow control and && / ||
for boolean operations. I will say: don’t use keyword versions (and / or / not
) at all (and go with more verbose if
s and unless
es). Less ambiguity, less confusion, less bugs.More: Difference between “or” and || in Ruby?
eql?
is NOT the same as ==
(and NOT the same as equal?
or ===
)
1 == 1.0 # => true 1.eql? 1.0 # => false
Good practiceUse only
==
operator.In detail
==
, ===
, eql?
and equal?
are all different operators, meant for different usage in different situations. You should always use ==
operator for comparing things, unless you have some specific needs (like you really need to differ 1.0
from 1
) or manually override one of the equality operators for whatever reason.Yes, the
eql?
version may look smarter than plain old ==
comparison, but does it really do what you meant it to do, like, just compare some things?More: What’s the difference between equal?, eql?, ===, and ==?
a ||= b is not a = a || b
A common misconception is that a ||= b is equivalent to a = a || b, but it behaves like a || a = b
In a = a || b, `a` is set to something by the statement on every run, whereas with a = || a = b, `a` is only set if `a` is logically false (i.e. if it's nil or false) because || is 'short circuiting'. That is, if the left hand side of the || comparison is true, there's no need to check the right hand side.
An example goes here:
h = {} def h.[]=(k, v) puts "Setting hash key #{k} with #{v.inspect}" super end # 1. The standard ||= approach h[:x] ||= 10 h[:x] ||= 20 # 2. The a = a || b approach h[:y] = h[:y] || 10 h[:y] = h[:y] || 20 # 3. The a || a = b approach h[:z] || h[:z] = 10 h[:z] || h[:z] = 20
Output:
Setting hash key x with 10 Setting hash key y with 10 Setting hash key y with 10 Setting hash key z with 10
here y is unnecessarily set twice because of the general approach we consider.
Note : Do not confuse [op]= with anything related to ||= or &&=. They're entirely different ideas and are implemented entirely different[ly].
super
is NOT the same as super()
class Foo def show puts 'Foo#show' end end class Bar < Foo def show(text) super puts text end end Bar.new.show('test') # ArgumentError: wrong number of arguments (1 for 0)
Good practice
This is one of the places where omitting the parentheses is not only a matter of taste (or conventions), but actually changes the program logic.
In detail
super
(without parentheses) will call parent method with exactly the same arguments that were passed to the original method (sosuper
insideBar#show
becomessuper('test')
here, causing an error, because parent method does not take any arguments).super()
(with parentheses) will call parent method without any arguments, just as expected.
Your exception must not be an Exception
class MyException < Exception end begin raise MyException rescue puts 'Caught it!' end # MyException: MyException # from (irb):17 # from /Users/amit/.rbenv/versions/2.1.0/bin/irb:11:in `<main>'(This code will not catch
MyException
and the message 'Caught it!'
will not be displayed.)Good practice
- When defining your own exception class, inherit from
StandardError
or any of its descendants (the more specific, the better). Never useException
for the parent. - Never
rescue Exception
. If you want to do some general rescue, leaverescue
statement empty (or userescue => e
to access the error).
- When you leave
rescue
statement empty, it means it will catch exceptions that inherit fromStandardError
, notException
. - When you
rescue Exception
(which you should not), you’ll catch errors you won’t be able to recover from (like out of memory error). Also, you’ll catch system signals like SIGTERM, and in effect you won’t be able to terminate your script using CTRL-C.
class Foo::Bar
is NOT the same as module Foo; class Bar
MY_SCOPE = 'Global' module Foo MY_SCOPE = 'Foo Module' class Bar def scope1 puts MY_SCOPE end end end class Foo::Bar def scope2 puts MY_SCOPE end end Foo::Bar.new.scope1 # => "Foo Module" Foo::Bar.new.scope2 # => "Global"
Good practiceAlways use longer, more verbose version with classes wrapped by modules:
module Foo class Bar end end
In detailmodule
keyword (as well asclass
anddef
) will create new lexical scope for all the things you put inside. So, ourmodule Foo
creates the scope'Foo'
in which ourMY_SCOPE
constant with'Foo Module'
value resides.- Inside this module, we declare
class Bar
, which creates new lexical scope (named'Foo::Bar'
), which has access to its parent scope ('Foo'
) and all constants declared in it. - However, when you declare Foo::Bar with this
::
“shortcut”:class Foo::Bar
, it creates another lexical scope, which is also named'Foo::Bar'
, but here, it has no parent, and thus, no access to things from'Foo'
scope. - Therefore, inside
class Foo::Bar
, we have only access toMY_SCOPE
constant declared at the beginning of the script (without any module) with value'Global'
.
Most bang!
methods return nil
when they do nothing
'foo'.upcase! # => "FOO" 'FOO'.upcase! # => nil
Good practiceNever depend on built-in
bang!
methods return value, e.g. in conditional statements or in control flow:@name.upcase! and render :showAbove code can cause some unpredictable behaviour (or, to be more specific, very predictable failure when
@name
is already in uppercase). Also, it is another example why you should not use and / or
for control-flow shortcuts. No trees will be cut if you add those two enters there:@name.upcase! render :show
attribute=(value)
method always returns passed value
, regardless of method return value
class Foo def self.bar=(value) @foo = value return 'OK' end end Foo.bar = 3 # => 3(Note that the assignment method
bar=
returns 3
even though we explicitly return 'OK'
at the end of its body.)Good practice
Never rely on anything that happens inside assignment method, eg. in conditional statements like this:
puts 'Assigned' if (Foo.bar = 3) == 'OK' # => nilThis will obviously not work.
More: ruby, define []= operator, why can’t control return value?
private
will NOT make your self.method
private
class Foo private def self.bar puts 'Not-so-private class method called' end end Foo.bar # => "Not-so-private class method called"(Note that if the method were private,
Foo.bar
would raise NoMethodError
.)Good practice
In order to make your class method private, you have to use
private_class_method :method_name
or put your private class method inside class << self
block:class Foo class << self private def bar puts 'Class method called' end end def self.baz puts 'Another class method called' end private_class_method :baz end Foo.bar # => NoMethodError: private method `bar' called for Foo:Class Foo.baz # => NoMethodError: private method `baz' called for Foo:ClassMore: creating private class method
I ain’t afraid of no Ruby Gotchas
Ruby gotchas listed above may not look like a big deal, and at first sight they may seem they are simple matter of aesthetics or conventions.Trust me – if you don’t deal with them, eventually they will lead to some nasty headaches during Ruby on Rails development. And will cause heartbreak. Because you’ll fall out of love with Ruby. And then you’ll stay alone. Forever... ;)