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!

Also published on Medium.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.