Posts

Fun Code of the Day #2: Does nil have a type?

Okay, no cheating now. That is, no running the code until you’ve guessed.

What is the output of this code?

How sure are you?

Now run it and find out. Were you right?

Flotsam and Jetsam #96

  • Quote of the Week: “In general, you should always strive to eliminate the passing of null rather than checking for null.” – John Sonmez
  • #DelphiWeek was fun.  I followed the hashtag on Twitter,  and saw all kinds of fun stuff, from people posting pictures of their old versions of Delphi (all the way back to floppies that held the very early versions of the beta.  I still have some of those –) to Ray Konopka’s Borcon buttons.  I was also honored to be interviewed for the event, talking about the early days of TSmiley and something I’m still proud of to this day – the fact that I was at the original launch event for Delphi.  It’s hard to believe that as I type this, that was twenty years ago today, but there you have it.  Delphi really is twenty years of continuous innovation, and it continues to prove worthy of that moniker. 
  • Rob Love has a really nice article on the Parallel Programming Library and using TTask properly.  Good example of how tricky parallel programming can be.  I’m working on that chapter for my new book and it is indeed a challenging topic, but one worth the effort.  Good reason to upgrade to XE7.
  • Andy Hausladen dog-fooded a new JSON parser for Delphi.  Worth a look, for sure.  I downloaded it, looked at the unit tests, and now I know how to use it.  See?  it really works that way.

On the Use and Acceptance of nil

Yesterday I made the following tweet:

and it started and interesting little discussion on Twitter.  (I was actually honored that the great Mark Seemann himself entered into the fray…) Naturally, the conversation tried to point out why I was wrong, and all the ways that it was fine to use nil.  That’s okay – if there it is one thing developers like better than making pronouncements, it’s finding exceptions and arguing against other developer’s pronouncements.

Well, I remain unconvinced and stand by my statement.  No surprise there, I know.

There are two parts to what I said and I’ll argue them one at a time.

First – “never pass nil to a method”.  Now people freak out about “never”, but it’s Twitter and you don’t have a lot of room for caveats.  First, sometimes I guess you have to pass nil to some methods  — ShellExecute  comes to mind —  but I’d argue that those methods are poorly designed (as I’ll talk more about in a minute), and that you should pass nil only very, very reluctantly.  Again, I’m talking about your code, not other’s code.    You should never send nil to a place where a valid object will be accepted.  Never do that to someone’s code.  Returning nil is always a bad design decision.

The Robustness Principle states, in part, that you should be very precise in what you pass, and passing nil is not precise.  It misses the mark by as much as you can miss the mark.  The target is a valid, working instance of whatever the method is asking for, and passing nil is like turning 180 degrees around and firing your arrow away from the bulls-eye.  Nil should not be used as a “signal”, leaving the class you passed it to in a state where they can’t make use of what you’ve given them.  You should avoid like the plague allowing a  class to be in a state where it can’t do what it is designed to do, and if it asks for a object in a method or constructor, you are obligated to pass a working, constructed object that it can use without error.  To do anything else is to invite an exception or worse, an access violation.

The second part is this:  “Don’t let your methods – especially your constructors — accept nil as a parameter value”.  Your classes should never let themselves get into an unusable state, and blindly accepting nil as a parameter will do that.  Instead, your classes should carefully guard against being passed nil and quickly – no, immediately – fail if passed a nil reference.  There is even a pattern – the Guard Pattern – that is employed to ensure that a program won’t continue unless things are acceptable.  Getting nil is not acceptable:

Every single time you accept an object as a method parameter, you need to use the Guard Pattern to prevent your object from being placed in a bad state where it can’t do what it is supposed to do. Fail fast and tell the user exactly what they did wrong and what they need to do to fix it. In fact, if a nil reference sneaks in, you’ll eventually get an access violation when you try to use this nil reference, right? Sure, it’s work, but it is time well spent.  Knowing that your references are always valid makes for easier code, and actually can reduce the amount of nil checking that you have to do.  Who wants to check for nil every time you use an object?

Don’t pass nil references.  Don’t accept nil references.  This seems obvious to me and I confess I don’t understand objections to this aphorism that only results in cleaner code.   Why would you ever want to accept a nil object?  Why would you want your code in a state that is begging for an access violation to occur?  Insist that your objects are valid, and never impose invalid objects – nil – on others.  Seems blatantly obvious to me.

So I am going to guess that this will not make some of you happy.  So here is my challenge:  Show me code that you have written where nil is acceptable.  Don’t show me code that calls the Win32 API or the VCL, show me code you have yourself written where nil is acceptable and useful as a valid method parameter.  I’d love to see it – and then point out the problems that it will cause.  🙂