Tag Archives: Wil Shipley

A Whole Load of Empty

I have a lot of respect for Jeff Atwood and his Coding Horror blog. He often has interesting and informed insights into software development, and generally knows what he is talking about.

Yesterday he posted an article under the heading “The Best Code is No Code At All” where, backed by comments from Wil Shipley he argues for the benefits of code brevity – put simply reducing the volume of code a developer has to read to understand how an application works. This is certainly something I agree with. However then he gives an example of a simple change to improve code brevity:

Instead of

if (s == String.Empty)

he suggests

if (s == "")

He backs the suggestion with the following statement:

It seems obvious to me that the latter case is better because it’s just plain smaller. And yet I’m virtually guaranteed to encounter developers who will fight me, almost literally to the death, because they’re absolutely convinced that the verbosity of String.Empty is somehow friendlier to the compiler. As if I care about that. As if anyone cared about that!

This is one occasion where I significantly disagree with Jeff on this when it comes to development in .Net.

Firstly, using “” is error prone. Put a space between the quotes, and the compiler won’t pick it up – it is still a valid string literal. It may be a minor change, but it will break your application, and is the kind of typo that is a pain to find. A typo in String.Empty will be picked up by the compiler, rather than coming up in testing, or worse still on a customer site.

Secondly, using String.Empty is more efficient (although as any .Net programmer should be able to tell you, checking the length of the string is more efficient still). To understand why String.Empty is more efficient it helps to understand how .Net handles strings. In .Net, a string is immutable – it never changes, so for example routines that concatenate strings together to build up database queries will be repeatedly creating new strings throughout the whole process. The .Net Framework helpfully provides a StringBuilder object to use in such situations. However the same is true when considering any literal, so “” has to become a string object, and yet you already have String.Empty which is exactly that.

However, .Net has another trick up it’s sleeve, in that it maintains something called the string intern pool. Every string literal is stored in this pool, and when a new literal is encountered that is already in the pool the version from the pool is used instead, saving the overhead of creating a new object. Whilst that speeds up literals somewhat, the application still has to do slight more than if it is just handed a suitable object straight off. Using String.Empty is slightly more efficient than “” – and it’s nothing to do with being friendlier to the compiler.

It’s entirely fair to argue that the performance differences are negligible in most situations, a point with which I’d agree, however the differences magnify if you are producing code with a lot of literals, and a lot of string comparisons. As an aside check out this posting from a former member of the CLR team at Microsoft where he ponders whether automatically interning the entire pool when an assembly is loaded is a good or bad idea.

Put simply, if you know you’re going to be repeatedly comparing to a string value, and performance is an issue, don’t use a string literal, as every comparison you’ll get the overhead of it looking up in the string intern pool – and if the string value is an empty string, don’t bother with either and use String.Length, or better still String.IsNullOrEmpty if there is the possibility that the string is null (or Nothing in VB.Net), both of which are faster than a string comparison in that situation.

So sorry Jeff – I see your point about brevity, but I’m sticking with String.Empty!

The Worst Response from a Company Spokesman?

This posting from Wil Shipley reports the response of Marco Pena, a Dell spokesman to the news that the new MacPro’s were up to $1000 cheaper than similar spec Dell machines. The response has to be read to be believed… Some of Will’s suggested alternative replies are quite amusing too. Seriously though, from the response you could almost believe that Dell are so comfortable in their position as a leading manufacturer that they think that they can’t be touched – but $1000 is a big price difference…

Career Tips from the Creator of Delicious Library

I came across an interesting article, written by Will Shipley, who created both Omniweb, a leading Mac browser, and more recently Delicious Library, a very impressive bit of software for keeping track of your CD and DVD collections.

The general gist of the presentation, given to students at the Apple World Wide Developers Conference is that you are more likely to make your fourtune in the Mac market because although the market is significantly smaller, there are also a lot fewer Mac developers around, as he says in the slides:

“Doing what ‘everyone else’ is doing is the surest route to failure.�

It is worth noting at this point that he claims that purely by word of mouth, Delicious Library made $54,000 profit on the first day.

Anyway, the slides are quite amusing, providing quite a good discussion starter on their own, and that’s before we get to his ‘recreation’ of the presentation for a podcast!