Reputation: 105
In my program I have a structure similar to the following one:
while (true) {
int c;
cout << "Type a command: ";
cin >> command;
switch (c) {
case 1:
// [...]
if (!condition) break;
// [...]
if (!condition2) break;
// [...]
if (!condition3) break;
// [...]
break;
case 2:
// [...]
break;
default:
break;
}
}
But our professor told us to never use the break
except in the switch case to exit... I was wondering if there's a better and smarter way to replace the block if(!condition) break;
.
My main goal is to prevent the program from doing certain actions if condition
is not verified.
Upvotes: 0
Views: 759
Reputation: 3506
In order to avoid break
you need to use the opposite condition, and instead of breaking the flow, control it:
switch (c) {
case 1:
// [...]
if (condition) {
// [...]
if (condition2) {
// [...]
if (condition3) {
// [...]
} // if the third condition is false, you will continue to the break.
} // if the second condition is false, you will continue to the break.
} // if the first condition is false, you will continue to the break.
break;
// ...
}
To avoid complex conditions, you can use functions:
void condition_1_actions();
void condition_2_actions();
void condition_3_actions();
// ... main ...
case 1:
if (condition) condition_1_actions();
break;
// ... After main ...
condition_1_actions() {
// do some actions
// Calculate condition2 or pass it as parameter
if (condition2) condition_2_actions();
}
condition_2_actions() {
// do some actions
// Calculate condition3 or pass it as parameter
if (condition3) condition_3_actions();
}
condition_3_actions() {
// do some actions
}
Upvotes: 1
Reputation: 8965
I'm sure that "your professor" would agree: "if it ain't broke, don't fix it."
The logic as-written is clear, and I presume that it works. Also, as-written it would be maintainable: I wouldn't have to radically change the source-code if when I needed to add a new condition to it. Just leave it alone. Anything that you hear from a professor – or anyone else – is a guideline!
"Clarity" is always key, because as years go by your source-code is going to be added-to by many others. I like the original idiom because each of the cases is clearly distinct: "make this test, and then bail-out." (Could be break
or return
depending on the situation.) It's very easy to see how the logic goes, and it's equally easy to add another case to it "in the same vein."
In the end – "it makes absolutely no difference to the digital computer." (As Perl programmers like to say, "there's more than one way to do it.™") But it might be attractive to your [future ...] colleagues. There are no absolutes here. Just try to be nice to them. Be "stupid-obvious."
Upvotes: 0