Q. When is a Boolean not a Boolean?

A. In the hands of dodgy Python developers ;^)

I just came across an example of my least-favourite(?) anti-pattern in Python – using “implicit” boolean values in conditional expressions. This particular occurrence was found in sample code in the “Google App Engine”, but it could have come from lots of places ;^)

...
user = users.get_current_user()
if user:
   # Do something...

else:
  # Re-direct to login page
...

The “get_current_user” method returns None if there is no user currently logged in, hence the poorly written “if user” test.

Now this is (obviously) perfectly valid code because in Python, empty lists, dicts, 0 (zero), None etc all evaluate to False, whereas a list or dict with at least one item, a non-zero integer, a non-None reference to an object etc. all evaluate to True…

Well, almost… and therein lies the problem! If, for example, an object instance implements the special method “__len__” and happens to return zero then it too would evaluate to False. Maybe what you wanted, and maybe not, but in my experience this has caused some weird, wonderful and subtle bugs (the best kind ;^). IMHO it is much better to use explicit boolean expressions where, errr, booleans are expected, and hence the above example should be:-

user = users.get_current_user()
if user is not None:
   # Do something...

else:
  # Re-direct to login page

I’m not sure why some Python developers insist on using the above pattern – do they really think that the typing it saved them reduced the overall development time? If so, maybe they also think of themselves as typists, not developers ;^)

Blocks and Procs

If a function/method uses a block, why would I ever use the implicit ‘yield’ syntax instead of explicitly pass the block as the final ampersand argument?

e.g.

Why would I do:-

def foo(x)
  yield x
end

Instead of:-

def foo(x, &block)
  block.call x
end

Doesn’t the implicit syntax hide the fact that the function/method allows a block from the caller, meaning that the only way to discover it is to read the code?!? What am I missing?

First Impressions…

And the first one is Frank Spencer… I’ll be here all week ;^)

I have to say, that the geek side of me likes much of what I see in Ruby so far… objects everywhere, blocks, the ability add to “re-open” class definitions etc. but the team developer side of me, however, ┬áis a bit more apprehensive.

My pet “thing” in software is finding tools and techniques to make the intent of programs clear. At the simplest syntactic level this comes down to what is usually referred to as “readability”. Martin Fowler famously said “Any fool can write code that a computer can understand. Good programmers write code that humans can understand”, and it seems to me that Ruby’s terseness is potentially more help to the computer ;^)

I think it comes down to a question of whether you think it is the transcription (i.e. typing) or the comprehension (i.e. reading and understanding) of code that is the tricky part. To add new features and to fix bugs a developer has to first determine the intent of the code and my hunch is that that takes somewhat longer than the typing required to make it happen.

So, that said, does anybody really think that we actually save time by typing ‘to_a’ or ‘to_s’ instead of ‘to_array’ and ‘to_string’?