True that.
but, there is still some reason to do that final test;
- For code clarity. You can never be too obvious about what your intentions are. If you can be any more obvious, do so.
- For functionality. Maybe at first the variable
was > theNumber, but then later it became not-less-than theNumber! How? who knows how... you'd be surprised. Maybe in a big multithreaded program some other thread changed the variable, or maybe someone who's using your code decided to edit it a bit to add some cool stuff and meanwhile caused this to happen. With overly obvious code, chances of having these unintended bugs sprouting around is very small. With shortened code (like typing "else cout << "higher" " thinking 'duh, its obviously less-than') the chances for bugs are greater...
For the same reason i prefer to put evey possible expected case in a switch statement, and leave the default case for something really unexpected. like;
- Code: Select all
// Example 1: wrong
switch(userChoice)
{
case CHOICE_1:
CallThisFunction();
break;
case CHOICE_2:
CallThatFunction();
break;
default:
// bah, the user probably made a bad choice
cout << "Please choose from the available choices"
break;
}
- Code: Select all
// Example 2: Correct
switch(userChoice)
{
case CHOICE_1:
CallThisFunction();
break;
case CHOICE_2:
CallThatFunction();
break;
case BAD_CHOICE:
// yep, i expected the user might choose something wrong
cout << "Please choose from the available choices";
break;
default:
cout << "Something is terribly wrong..."
break;
}
You're probably thinking "That defualt case in example 2 will never be reached"
Well, You'd be surprised... very surprised
Example 2 in a way is much more bug-proof than example 1
Just my personal opinion though