tags:

views:

109

answers:

8

Just one quick question, say, Car class extends HashMap(String, String).

1.

for (Car car : carList) {
    if (car.isEmpty) {
        break;
    }
    doSomething();
}

2.

for (Car car : carList) {
    if (!car.isEmpty) {
        doSomethingElse();
    }
}

Which of the above two is better? Thanks.

---- edited ---- Sorry I did not make my point clear.

The doSomething() method is actually doing different things. I've changed them to doSomething() and doSometingElse().

My question is, will you put all the process in one if()? or first break the loop if the if() condition does not satisfy.

Thanks.

+1  A: 

They do completely different things. First one will stope after seeing first empty car. Second version will 'do something' for each non-empty car. I think, you might want to use continue operator instead of break.

Nikita Rybak
+8  A: 

They do completely different things. The former will stop iterating as soon as the condition is true, whereas the latter will merely skip the processing during the iterations where the condition is false.

Changing the break to continue in the first will make them work the same way.

Ignacio Vazquez-Abrams
Sorry I did not make my point clear, I've edited the post, thanks
Gnavvy
Except the second one calls dosomethingelse() while the former calls dosomething().
Matt H
A: 

These 2 loops don't do the same thing

  1. will terminate the loop the first time it finds an empty car with isEmpty skipping any cars after the first empty one. You can make this work like 2. if you change 'break' to 'continue'

  2. will doSomething for all not-empty cars.

kkress
thank you for your answer. I'm sorry that I did not make my point clear, I've edited the post, thanks
Gnavvy
A: 

Depends on what are you trying to do, the first loop will end as soon as the condition is meet, while the second one will iterate throuh all the hashmap.

james_bond
A: 

If you actually meant "continue" and not "break", then I'd say not using continue or break is better.

It's not a huge deal, but statements like continue, break and return are all essentially goto statements that have been dressed up a little. Instead of goto a line or goto a label they goto the top or bottom of a control structure--it makes the programmer have to think a little bit when they track it which means wasted time and additional chances for errors.

It's not a terribly big deal, and many times these structures will actually clarify your code, but if you have a choice and they seem to do essentially the same thing, go the way that doesn't involve sending control elsewhere.

Bill K
Thanks Bill. I was considering break because it just make the code a little easier to read.
Gnavvy
I would argue that less code is more readable in this case than more code (with the break statement). You can have less code by inverting the condition and not needing a break/continue.
matt b
@matt b Not really, the "Less code is more readable" is kind of a fallacy unless you are talking 20 lines of code extra or so. Changing one compact line to two or three lines will almost always be more readable (I cringe every time I see the word "Expressive" these days).
Bill K
@Gnawy If you are actually using a "Break" to jump OUT of a loop early, that is reasonable--If you use break/continue to simplify a series of nested control structures, it's fine. In the case you listed, the break (Which I still believe you meant continue) makes things actually read worse. If it removes complication and you can't find an easy way to remove the complication without it--go for the control structures... I was just saying in general to weight them a little bit towards bad...
Bill K
Not sure it can be said it's a fallacy. It's a subjective statement.
matt b
@matt b I suppose, but I've found that outside the author (who always thinks his code is most readable as written) it's pretty much always true that more explicit is more readable.
Bill K
@Gnawy just an aside, easier to read, as matt b said, is somewhat subjective. I'd assert that the coder is the worst one to judge. If you have a case like that you might write both of them and ask someone else. Programmers are notorious for finding really cute tricks that cut a line out then becoming really attached to them. I'd actually suggest all programmers get in the habit of finding the greenest coder in your company and asking which takes less time to read--I mean that's the person who will waste the most time decoding something difficult or waste your time making you describe it.
Bill K
A: 

If you want different behavior based on if the car is empty or not, you can use an if else statement. Use break if you want to stop iterating carList.

for (Car car : carList) {
   if (car.isEmpty) {
      doSomething();
   }
   else {
      doSomethingElse();
   }
}
HappyFunCoder
A: 

As everyone has pointed out, the break version will exit early. The answer then depends on what you want it to do.

If you've finished doing what you need to do then break out as soon as you're done. Why waste CPU cycles? on the other hand if you must go through the whole list to dosomethingelse() then don't break out.

Were you meant to have two different named functions or should they both be called dosomething() ?

Matt H
A: 

Is this what you're looking for?

for (Car car : carList) {
    if (car.isEmpty) {
         doSomething();
    }
    else {
         doSomethingElse();
    }       
}

Or are you looking for

for (Car car : carList) {
    if (car.isEmpty) {
       break; 
       //STOP ITERATING THROUGH THE REST OF THE LIST 
       //(doSomething & soSomethingElse may have been called a few times already)
    }
    else {
        doSomething();
    }
    doSomethingElse();
}

There are other options as well, your clarification still isn't clear... to me anyway...

MadMurf
thanks MadMurf, your answer is right. I just wanted to move the doSomethingElse() out of the if() part. the post in paxdiablo's comment is what I was looking for.
Gnavvy