break isn't technically needed after the last alternative (which, mind you, doesn't have to be default: it is perfectly legal, and sometimes even useful to put the default branch first); whether your code falls through the end of the switch statement or breaks out at the end of its last branch has the same result.
However, I'd still end every branch, including the last one, with a return or break statement, for three reasons:
- Refactorability. If all your branches end with
break or return, you can reorder them without changing the meaning. This makes it less likely for such a reordering to introduce a regression.
- Consistency, and Least Surprise. Consistency says your branches should end consistently, unless they are actually different in meaning. The Principle of Least Surprise dictates that similar things should look similar. Ending the last branch of a
switch block exactly like the preceding ones fulfills both, which makes for easier reading and understanding. If you leave out the explicit break, the last branch will be optically different (which is especially important for quick scanning), and in order to see that it's really not different, the reader has to descend to the nitty-gritty level of reading individual statements.
- Protecting yourself. If you make a habit of ending all your
switch branches with a break, it will become automatic after a while, and you'll be less likely to accidentally forget it where it does matter. Training yourself to expect the break at the end of every branch also helps detecting missing break statements, which is great for debugging and troubleshooting.
You are not simply checking the value of a for the sake of it. It probably means something.
Thus I would prefer to see:
Boolean sell = a < 5;
Boolean buy = a > 10;
Boolean error = a >= 5 & a <= 10;
// or even:
Boolean error = !sell & !buy;
/* ^ (that's single source principle: if 5 changes to 6 one day,
* you don't have to remember to change it in two places) */
And then:
if (sell) {
} else if (buy) {
} else if (error) {
}
Isn't it clearer?
Furthermore, could a be both less than 5 and greater than 10??
Rather not, so those elses are clearly redundant. (Unless you change the value of a within one of your if blocks, mind you, If you only evaluate a once, however - as in my example - you don't have to worry about it).
Hence:
Boolean sell = a < 5;
Boolean buy = a > 10;
Boolean error = !sell & !buy;
if (sell) {
}
if (buy) {
}
if (error) {
// handle error
}
This is way clearer and more flexible in my opinion - if some conditions are no longer mutually exclusive, as it can happen, you won't need to do much refactoring at all.
Best Answer
It seems there are three cases when a
defaultstatement is not necessary:no other cases are left, because there is a limited set of values that enter the
switch case. But this might change with time (intentionally or accidentally), and it would be good to have adefault caseif anything changes _ you could log or warn the user about a wrong value.you know how and where the
switch casewill be used and what values will enter it. Again, this might change and an extra-processing might be needed.other cases do not need any special processing. If this is the case, I think you are asked to add a
default case, because it is an accepted coding style, and it makes your code more readable.The first two cases are based on assumptions. So (assuming you work in not-so-small team since you have regular code reviews), you cannot afford making those assumptions. You don't know who will be working with your code or making calls to functions/invoking methods in your code. Similarly, you might need to work with someone else's code. Having the same coding style will make it easier to deal with someone's (including your) code.