Is checking count/size/length less than 0 necessary in modern languages anymore? For instance, in C# I quote often will check if a collection's count is less than or equal to 0.

I assume that this was done in older languages, like C, where you could potentially have a size of less than 0.

Is there ever a case where you can have the size/length/count of an object or primitive type be less than 0?

  • Are you only asking about a.Length != 0 versus a.Length <= 0 (and the equivalent form using <)? A slightly different but related question (which you may be getting at with this) is why signed types are used for length and indices, permitting nonsense like negative lengths.
    – user7043
    Jan 9, 2014 at 22:03
  • if the collection is designed right, the count/size/length should be unsigned int/uint, which is impossible to have negative value
    – Bryan Chen
    Jan 9, 2014 at 22:29
  • @BryanChen: The framework classes are not designed that way, because then they would not be CLS compliant.
    – Guffa
    Jan 10, 2014 at 0:35
  • 1
    Years ago, defensive coding techniques were all the rage. Programmers were taught to write a.Length <= 0 rather than a.Length != 0, because you can't always trust the computer to return a positive value. I still code a.Length <= 0, because I'm covered if the value is negative. It's the same reason I code a.Length >= maxValue to end a loop. Jan 10, 2014 at 13:34
  • Since you mentioned C, personally I think a good C coder will never use a signed integer for sizes, in which case <= 0 would be by definition equivalent to == 0. (And before anyone mentions the signed ssize_t or something like it, I'd say that type is semantically not purely size - it's overloaded for reporting errors, and all uses I know of, by the time you're using it as size, you should either assign it into size_t, or you already know it's not negative.)
    – mtraceur
    Apr 8, 2016 at 6:26

2 Answers 2


In the .NET Framework (of which the C# language is a part), most ordinary indexes (with the notable exception of file positions, which use a 64 bit signed long) are standardized to a signed, 32 bit int.

So, for example, when you get the length of a string, you're being returned a number that can hold negative values, but in practice, will never be negative.

However, that's not true of all string operations. IndexOf() still returns a signed int, but will return a value of -1 if the search string is not found. This is partly why signed int was chosen for such indexes; to provide the possibility of returning negative values for signaling purposes.

Because signed integers are always returned from such operations, the code

if (s.length <= 0)

is consistent with the idea that "I'm checking to see if this string has something in it," since all such lengths will be a positive number.

But you're right; technically it's not necessary to check for a negative number in those cases where you'll never get one (i.e. Length).

  • 4
    IndexOf will return 0 if the search string is found at the beginning of the string.
    – poke
    Jan 10, 2014 at 0:03
  • 1
    Yes, that's right. (?) Oh, I see what you're getting at. Jan 10, 2014 at 0:04
  • 1
    And so we see why Haskell has Maybe and Scala has Option...
    – itsbruce
    Jan 10, 2014 at 11:39

You can use Any which will return as soon as if there is an item in the collection, whereas using Length will actually iterate through the whole collection and count it, which is a bad idea. So Any is lazy, Length is eager. Most of the cases, Any is sufficient.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.