4

Often, people say that it is better to say s.Length == 0 instead of s == "". But it seems like this would be a microoptimization that also makes it harder to read. Also, ten million of the former as opposed to the latter save at best 60 ms.

Is there a reason that I'm missing, such as if perhaps s.Length == 0 actually conveys the intent better? Or is it common to need to compare many strings for emptiness?

EDIT: I know about IsNullOrEmpty, but when people answer the question, they often mention that length checking is better than comparing to the empty string.

EDIT2: Not asking about the best way to do this which would be IsNullOrEmpty for both cases, but I'm asking why it is that a non-negligible minority insist that length checking is superior. I'm assuming that they have some good reasons for saying so, and want to know what they are.

EDIT3: As stated in the beginning, I do know that one is faster than the other. The question is, is that the reason people recommend it? Some timings showed that this did not lead to significant differences.

Jamie
  • 3,901
  • 3
  • 23
  • 27
  • 3
    I would rather use `string.IsNullOrEmpty()` in case I trip on null reference exceptions... (accidentally swallowed my comment) – BoltClock Jun 16 '11 at 17:46
  • 1
    Who says "it is recommended"? Its actually IsNullOrEmpty/IsNullOrWhitespace that is recommended. –  Jun 16 '11 at 17:55

6 Answers6

7

You're right, it's essentially a micro-optimisation. Testing the length does keep FxCop / Code Analysis quiet though - and the justification is performance, as documented in MSDN.

As for which is more readable, that's subjective, and I'm sure any developer would understand either. Since they are semantically different (s.Length == 0 throws if s is null, whereas s == "" doesn't), readability isn't the only criterion to consider.

In cases where you're not certain the string is not null, String.IsNullOrEmpty or String.IsNullOrWhiteSpace might be even more readable (i.e. expressive of your intention).

Joe
  • 122,218
  • 32
  • 205
  • 338
2

The reason is by doing s == "" you are doing a string comparison which is slower than the other way (s.Length == 0)

Naftali
  • 144,921
  • 39
  • 244
  • 303
  • 2
    Not very significantly; .net strings know their length; this is checked first – Marc Gravell Jun 16 '11 at 17:47
  • I would be very shocked if the JIT'd code is not the same for both checks. – Josh Jun 16 '11 at 17:56
  • 1
    It seems like the JIT'd code would at least have to be somewhat different, as the first would return false and the second would throw an exception in the case of a null string. – Jamie Jun 16 '11 at 18:03
1

In most of my code, using string.IsNullOrEmpty() or string.IsNullOrWhiteSpace() (in .NET 4) are easier to read and more specifically do what I really need done.

ShaneBlake
  • 11,056
  • 2
  • 26
  • 43
0

s == string.Empty is an alternate to s.length == 0.

My guess on why s == "" is not recommended is that "" would create a immutable string on heap. Just for comparison, you may not want to create a string object. Anyhow someone may validate my statment.

SaravananArumugam
  • 3,680
  • 6
  • 33
  • 45
  • 1
    I was under the impression that almost all empty strings in code shared the same instance. – Jamie Jun 16 '11 at 17:54
  • "" is an immutable string literal. You can see that ("") would have all the properties that a string variable can hold. That's the reason I wrote that you are creating a string object for your comparison. – SaravananArumugam Jun 16 '11 at 18:00
  • I get that, but it seems like all of the ("") would refer to the same string, via interning (http://stackoverflow.com/questions/263191/in-c-should-i-use-string-empty-or-string-empty-or) – Jamie Jun 16 '11 at 18:02
  • Hmmm. That's a news to me. Thanks. – SaravananArumugam Jun 16 '11 at 18:06
  • I haven't checked the official csc, but Mono's compiler (dmcs) actually does `ldsfld string [mscorlib]System.String::Empty` before `call bool string::op_Equality(string, string)`, even if `""` was used in source code. So no unneeded string instance is created. – Jakub Januszkiewicz Jun 16 '11 at 18:15
0

String values comparision is slower than numeric values comparision.

I would use String.IsNullOrEmpty in your case.

Akram Shahda
  • 14,655
  • 4
  • 45
  • 65
0

not all dot net strings are interned at runtime that means that s.Length == 0 would be faster in those cases as it avoids an actual string comparison which results if one of two strings is not interned See String.IsInterned() on MSDN

Jack
  • 4,684
  • 2
  • 29
  • 22