Flotsam and Jetsam #94

Flotsam and Jetsam #93

  • In my post about my new book, I mentioned that I thought my outline was a little thin, and indeed it was.  I left out a large topic about which I planned on writing – “Writing SOLID Code”.  Add that in, and things seem a bit more fleshed out.  The silly thing was that I was working on that chapter when I put together the outline and wrote the blog post.  Anyway, the outline has been updated and all is well.  Thanks again for the support.  If you want to keep up with the book’s progress, help out answering my silly questions, and generally be supportive, you can sign up at the LeanPub site, or you can join the Google Group
  • Here’s some food for thought for my post about not using nilThe Null Object Pattern.  Yet another reason never to return nil.  Instead of doing that, you can return a null object that won’t cause an access violation and yet won’t do anything.  You can check if the object is a null object if you need to.  Win all around.
  • So the rumors were true – Embarcadero has bought the main products of TwoDesk Software.  Jacob Thurman has stated that while he’s not now an Embarcadero employee, he will be working on the Delphi IDE.  I guess it’s none of our business exactly what the relationship will be, but if Jacob is working to improve what the IDE can do with code and to improve developer productivity in the Code Editor, I’m very happy.  I know that Jacob has had a lot of things that he wanted to do, but found it difficult as an “outsider”.  Now that he’s an “insider”, I hope he can do them.  I think we’ll see some fun stuff coming out of this deal. Congratulations to Jacob, who I hope was well remunerated, and to Embarcadero for the wisdom to see and acquire Jacob’s skills.
  • True words tweeted by me: “There are two things that developers love to do: Make pronouncements, and point out the exceptions to other developers’ pronouncements.”  I like to make pronouncements as you’ve probably noted.  I’m always trying to learn new things and new ways of doing things, and I don’t want to be held back by the “well, we’ve always done it that way” way of thinking.  I believe that the way software is developed is evolving and improving, and that we’ve found new ways of doing things better.  I try to learn those things and blog about them.  That’s what I’m trying to do here.  If you disagree with what I say, I welcome your comments. But I ask you to consider that maybe I’m actually on to something.  I’d encourage you to take the same path I have – the path of learning these new things that developers are finding and doing.  For instance, I don’t ever intend on writing another Delphi application without utilizing MVVM.  But ten years ago, such a thought would have occurred to almost no Delphi developer.  I encourage you to study the SOLID principles, to read Clean Code, to find better ways to decouple your code, and to generally seek out new thinking about software development.  I’m a firm believer that there is always a better way, and I encourage you to think so as well.

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.  🙂

Delphi and #Code2014

Hey, Delphi ended up really well in the #code2014 survey.  Sure, it’s self-selected and thus statistically dubious, but it definitely is nice to see Delphi in ninth position with a prominent circle.  (If you add Delphi and Pascal together, we’d be in sixth place.  Yes, I can see the comments already…)

If I were part of EMBT’s marketing team, I’d be shouting this one from the mountain tops.  I know that technically it’s not statistically significant, but the whole chart “feels” right.  The languages at the very top seem like the right ones.  And Delphi at the ninth position seems right too.  Why?  Because I think there are a lot more Delphi developers out there than people know.  Is it more popular than C/C++?  Maybe not, but then again, maybe it is.  No way to know. 

The part that bums me out is the community members that are so quick to point out that the survey “doesn’t mean anything”.  I most strongly disagree.  I think it means a lot.  I think it shows that the Delphi community is real, it’s bigger than folks think, and it’s willing to speak up and be heard.  All I know is the Delphi community sure came out of the woodwork and made Delphi rise into a prominent position in a poll that many developers will see. That can’t be bad.  It is good.

If you are a Delphi developer, you should be happy about this, and you should be doing what you can to show people the results.  I took a screen capture of the results in case the URL goes away (www.code2013.com is for sale for a mere $3095).  If you are a Delphi developer and are poo-pooing the results, I say “Lighten up, Francis”. 

This is good.  Enjoy it.  Use it.  Delphi is still here and going strong, almost twenty years after it launched.  We’ve had our ups and downs, but the bottom line is that you have nothing to be ashamed of when you say “I am a Delphi developer”. 

Flotsam and Jetsam #92

  • We have a vibrant .Net community here in the Eastern Pennsylvania/Philadelphia area.  Philly.Net runs events once or twice a month at the Microsoft campus, and semi-annual Code Camps that are usually attended by well over 700 people.  I attend whenever I can.  But I’ve noticed something interesting over the last year or two:  almost all the coding topics are now Javascript-based.  I see them doing very few C# – based presentations.  This event is pretty typical.  (I am going to be attending this one, by the way…..) Anyway, just an observation that I think is interesting.
  • If you aren’t satisfied with the RAD Studio IDE’s bookmarking system – and you shouldn’t be as it leaves a lot to be desired – you might be interested in the free IDE plugin called Parnassus Bookmarks from David Millington.  It works great, is totally free, and is a solid replacement for the existing system.   Download and install is recommended.
  • Well, Delphi has done really well in the #Code2014 survey.  Thanks to everyone who tweeted.  It’s nice to see Delphi up near the top in a very respectable position.  As of this writing, Delphi is only 19 tweets behind C++ – nothing to blow your nose at.    Javascript continues to dominate in a pretty big way, nearly doubling the second place Python.  (See my comment above).
  • New Project of the Week:  Another gem from the inestimable Malcolm Groves – TStateMachine.  From the README:  “TStateMachine is a framework for declaring and running state machines in Delphi. It supports generic types for states and triggers, anonymous methods for Guards and Effects (State.OnEntry? and State.OnExit?), and a Fluid interface for configuring the State Machine.”  Very interesting and worth a look.  Maybe even worth a new chapter in my book.
  • Cary and Ray have set the agenda for their Delphi Developer Days conference.  Again, this is always a high-quality event, and I try to make it every year.  Word of advice: Don’t ever miss Ray Konopka when he is speaking.  He’s very, very good.

More Coding in Delphi

First of all, I want to once again thank all of you who have purchased, read, or otherwise supported my book Coding in Delphi.  I’ve said it before and I’ll say it again  — the response has been overwhelming and humbling.  The book has been more successful than I could have ever hoped for.

It’s so successful, in fact, that I’ve decided to write another one – More Coding in Delphi.  I am once again using the LeanPub publishing platform.  LeanPub is really an interesting tool – it makes it really, really easy to produce a book. Highly recommended.  You write the book in Markdown, and they take that and turn it into PDF, MOBI, and ePUB files for you.  Easy as pie.  I’ve been using MarkdownPad for writing the book.  It does a nice job of helping you write Markdown text. 

By default, LeanPub uses DropBox.  First, I granted LeanPub access to a shared folder on Dropbox.  Then, when I go to publish a preview or the real thing, LeanPub looks in that folder for a file called “Book.txt” which describes the format of the book by pointing to *.md files.  It then accesses those files in the shared folder and creates the book. 

This time around, though, they’ve added a new feature where you store the book in GitHub and they pull from the repository to get the files for the book.  Cool.  When the book is ready for proofing by any of you interested in doing so, you’ll get access to the manuscript by pulling it from the private repository on Github.  So if you want to help out, you’ll need to brush up on your Git. SmileIt also means that I get the benefits of a DVCS, and you guys can make pull requests if you have improvements for me. 

Right now, the outline for More Coding in Delphi is currently:

  • Four Thoughts on Coding Before We Start
    • Encapsulation, CQS, Postrel’s Law, Compostion over Inheritance
  • Duck Typing
  • JSON
  • Aspect-oriented Programming
  • Design Patterns
    • Observer Pattern
    • Adapter Pattern
    • Decorator Pattern
    • Another Pattern to be named later
    • Another Pattern to be named later
  • Parallel Programming
  • Model-View-ViewModel

That feels a little thin to me right now, so I am seeking more topics.  If you want to suggest anything, I’m all ears — either comment here on this post, or join the Google Community for the book.  Remember the philosophy of the book, though – it’s all about the code.  I’ll write about code frameworks, RTL type stuff, etc., but I don’t want too many screen shots of forms in the book.  There will be some in the MVVM chapter, but the idea is that the book covers code and how to write good code.   That’s what I want to focus on.  I’m also open to turning “Four Things” into five or six or seven things, so if you have small topics – a page or two, not enough for a full chapter — I’d love to hear those as well.

Okay, so now the real work begins.  It’s a lot of work to write a book. My hope is to have the book published by the end of this year.  I know that I can’t do it without your help – you guys made the first book possible.  Again, I’m grateful to all you readers and supporters.