35
List<String> listStr = new ArrayList<String>();

if(listStr.size == 0){

}

versus

if(listStr.isEmpty()){

}

In my view one of the benefits of using listStr.isEmpty() is that it doesn't check the size of the list and then compares it to zero, it just checks if the list is empty. Are there any other advantages as I often see if(listStr.size == 0) instead of if(listStr.isEmpty()) in codebases? Is there is a reason it's checked this way that I am not aware of?

Bonifacio2
  • 3,405
  • 6
  • 34
  • 54
blue-sky
  • 51,962
  • 152
  • 427
  • 752

4 Answers4

43

The answers to this question could give you the answer. Basically, in implementations of some lists the method isEmpty() checks if the size is zero (and therefore from the point of view of performance they are practically equivalent). In other types of lists (for example the linked lists), however, counting items require more time than to check if it is empty or not.

For this reason it is always convenient to use the method isEmpty() to check if a list is empty. The reasons for which such a method is provided in all types of lists are also related to the interface, since ArrayList, Vector and LinkedList implement the same List interface: this interface has the isEmpty() method; then, each specific type of list provides its implementation of isEmpty() method.

Community
  • 1
  • 1
enzom83
  • 8,080
  • 10
  • 68
  • 114
  • 2
    Nice answer, just one comment: LinkedList's implementation of size() doesn't traverse the list, but rather keeps track of size as new elements are added or removed. Therefore, LinkedLists' performance of size() versus isEmpty() (which they inherit from AbstractCollection) do not differ at all. With that said, I agree that there might be data structures that have slower implementations of size() than isEmpty() but a reasonable implementation wouldn't.. Also, I believe you could also mention the DRY principle in here as a checking if size() == 0 is already done for you in most isEmpty() methods. – Nikola Yovchev Aug 22 '12 at 15:17
15

No, there's no reason. isEmpty() expresses the intent more clearly, and should be preferred. PMD even has a rule for that. It doesn't matter much, though.

taz_13
  • 7
  • 4
JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • Exactly. Also, look it up in the javadoc. Some implementations call size() from isEmpty() anyway. – YRH Feb 18 '12 at 14:01
11

.size() can be O(1) or O(N), depending on the data structure; .isEmpty() is never O(N).

Vatine
  • 20,782
  • 4
  • 54
  • 70
Julian Fondren
  • 5,459
  • 17
  • 29
  • 1
    I don't see why isEmpty would always be O(1) (but I agree that isEmpty() should always be at least as fast as size()). It could very well depend on the data structure as well. I'm not aware of any standard collection where size is O(n). Is there one? – JB Nizet Feb 18 '12 at 14:09
  • 1
    Please attempt to imagine one. Any structure with a sentinel - a C string, an array of pointers terminated by NULL, a list of cells terminated by nil. All of these can underly a hybrid type that caches the length, but that isn't free. ConcurrentLinkedQueue – Julian Fondren Feb 18 '12 at 14:43
0

While isEmpty() may express the intent better as JB Nizet suggests. If you are an old school programer, your style may lean towards expressions like .size() > 0 etc. So if the answer can be an opinion on ones intent, the answer can also be do what your muscle memory tells you.

In many cases size() and isEmpty are virtually the same as others have said. And if you are going to write software you don't want to optimize prematurely. I think the curiosity is justified in the question, but to be effective / efficient, code the way thats natural for you if optimal performance isn't critical. Dwelling on these subtle behaviors could actually waste your development time.

visc
  • 4,794
  • 6
  • 32
  • 58