Forum: Ruby why not check for nil?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Fbb4d027695dfdf76bf448b15d7e306a?d=identicon&s=25 matt neuburg (Guest)
on 2009-02-21 18:25
(Received via mailing list)
A post I ran across on a rails forum reads:

"Warning! DO NOT test for nil! This is a very bad coding practice. You
can use "if obj", but do not use "if obj.nil?" or whatever."

Is that generally true? Why? m.
Bec38d63650c8912b6ba9b557fb953b9?d=identicon&s=25 Roger Pack (rogerdpack)
on 2009-02-21 18:36
matt neuburg wrote:
> A post I ran across on a rails forum reads:
>
> "Warning! DO NOT test for nil! This is a very bad coding practice. You
> can use "if obj", but do not use "if obj.nil?" or whatever."
>
> Is that generally true? Why? m.

because it might be false [not nil]?
-=r
Fbb4d027695dfdf76bf448b15d7e306a?d=identicon&s=25 matt neuburg (Guest)
on 2009-02-21 19:11
(Received via mailing list)
Roger Pack <rogerpack2005@gmail.com> wrote:

> matt neuburg wrote:
> > A post I ran across on a rails forum reads:
> >
> > "Warning! DO NOT test for nil! This is a very bad coding practice. You
> > can use "if obj", but do not use "if obj.nil?" or whatever."
> >
> > Is that generally true? Why? m.
>
> because it might be false [not nil]?

Yes, I thought of that too. But of course to me that is *why* I would
check for nil (I really really do want to know if it's nil).

Maybe the poster just didn't know what he was talking about... m.
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-21 19:16
(Received via mailing list)
Roger Pack wrote:
> matt neuburg wrote:
>> A post I ran across on a rails forum reads:
>>
>> "Warning! DO NOT test for nil! This is a very bad coding practice. You
>> can use "if obj", but do not use "if obj.nil?" or whatever."
>>
>> Is that generally true? Why? m.
>
> because it might be false [not nil]?

Technically yes, but that admonition has more meanings (some of which
may have
escaped that original rails poster).

Consider this pattern:

   if @user
     render :partial => 'premium_content' # for logged-in users
   else
     render :partial => 'teaser_content' # for the great washed masses
   end

That is sloppy programming because it asks @user for its type (are you a
logged-in user? or just a slovenly nil?)

The correct pattern is @user is never nil, and if no user is logged in,
then it
should hold a "Guest" object. Then User and Guest can provide different
methods
for the same messages (method names):

   render :partial => @user.content_template

That pattern collects many redundant 'if' statements into one place;
that
technique is the heart of all OO programming.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-21 19:40
(Received via mailing list)
Hi --

matt neuburg wrote:
>
> Yes, I thought of that too. But of course to me that is *why* I would
> check for nil (I really really do want to know if it's nil).

Definitely use #nil? if you want to know whether something is exactly
nil. There are certainly a lot of unnecessary calls to #nil? out there,
but it doesn't follow that it can never be right to test for nil.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-21 20:36
(Received via mailing list)
David A. Black wrote:

> Definitely use #nil? if you want to know whether something is exactly
> nil. There are certainly a lot of unnecessary calls to #nil? out there,
> but it doesn't follow that it can never be right to test for nil.

Let's call this the "non-suicidal Samurai Principle". Either return
victorious,
or return empty-handed. (And don't waste my expense training you, duh!)

How many times have we written...

   def samurai
     blah and blah or blah
   end

   if samurai
     ...

...and then never bothered to check - even with unit tests, whether a
failing
samurai() call returned a nil or a false? Ruby's break with incorrect
tradition
- letting 0 be true - cleaned up a whole lot of clutter. .index() can
easily
distinguish "found at 0 index" from "not found". But this means we no
longer
always need to track which of those blah() calls returns a nil, which a
false,
and which one the boolean short-circuiting collects for us.
F53b05cdbdf561cfe141f69b421244f3?d=identicon&s=25 David A. Black (Guest)
on 2009-02-21 21:20
(Received via mailing list)
Phlip wrote:
> How many times have we written...
> incorrect tradition - letting 0 be true - cleaned up a whole lot of
> clutter. .index() can easily distinguish "found at 0 index" from "not
> found". But this means we no longer always need to track which of those
> blah() calls returns a nil, which a false, and which one the boolean
> short-circuiting collects for us.
>

I didn't say you should always do it, simply that if you want to know
whether an object is exactly nil, use #nil?. If you don't, don't :-)

There's an interesting case of nil overloading that I've never seen any
very nice workarounds for, though it probably occurs rarely if at all:

   a = [1,2,3,nil,"abc"]
   r = a.find {|e| !e }

r will be nil -- but it will also be nil if a doesn't contain nil.
Fortunately not an everyday problem, but an interesting case of
difficulty distinguishing found from not found.


David

--
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (http://manning.com/black2)

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09
This topic is locked and can not be replied to.