Switch boolean.... (reinventing if, unnecessarily)
-
If you are sure that the function argument named enabled is bool forever? If yes than there is no reason for the switch. If chacne to change the argument type is exist so - I would add into the switch
default:
FirstControl.Enabled = enabled;
SecondControl.Enabled = enabled; // :laugh:Al Chak wrote:
If chacne to change the argument type is exist so - I would add into the switch
There's no reason to add a
switchstatement now just in case the argument type changes in six months. Add theswitchwhen you need it - ie: when the argument type changes. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Scott Corbett wrote:
A switch will continue to fall through until you get to a break statement or the end of the switch (i.e. the default case.)
Not in C# - every case is required to have a terminating statement (
break,goto,returnorthrow).Unlike C++, C# does not allow execution to continue from one switch section to the next. ... C# requires the end of switch sections, including the final one, to be unreachable. That is, unlike some other languages, your code may not fall through into the next switch section.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
You're right about the switch case and fall through. Been spending too much time playing with C++ lately. My apologies.
Scott E. Corbett
-
Came across this kind of code today...
void EnableFromValue(bool enabled)
{
switch (enabled) {
case true:
FirstControl.Enabled = true;
SecondControl.Enabled = true;
...
break;
case false:
FirstControl.Enabled = false;
SecondControl.Enabled = false;
...
break;
}
}I'm sure there must be a better way ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
If it is not break-en, don't switch it? [[Thank you, I'm here all week; try the veal...]] Chaos.
-
Came across this kind of code today...
void EnableFromValue(bool enabled)
{
switch (enabled) {
case true:
FirstControl.Enabled = true;
SecondControl.Enabled = true;
...
break;
case false:
FirstControl.Enabled = false;
SecondControl.Enabled = false;
...
break;
}
}I'm sure there must be a better way ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
well, switch is shorthand for the if--then--else construct.
#SupportHeForShe
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
-
So do other things in the switch, but set the common values just once outside the switch ... duh. It's the DRY principle, and duplicating the code in each branch of the switch is not only stupid, but error prone.
:thumbsup:
#SupportHeForShe
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
-
I see a reason for the function but not for the switch statement. Except if you are paid by lines of code of course. :-D
The good thing about pessimism is, that you are always either right or pleasently surprised.
If they had a default: case then I could almost see a reason. Consider the case if the bool was neither true or false. For most x86 C's there are 254 other trues and 65534 other trues on the DSP I code. I remember some very picky standards about what to do with unexpected values for space computing. Pesky alpha/beta/gamma particles flipping RAM cells around and the like. I have fixed my share of mixed boolean true logics gone bad. Is it a one, -1 or non-zero? If true == mySupposedBool can be very tricky to find in C when mySupposedBool = -1 from some other language interface. At least false seems to always == 0. ----- I love standards, there is so many to choose from!
-
If they had a default: case then I could almost see a reason. Consider the case if the bool was neither true or false. For most x86 C's there are 254 other trues and 65534 other trues on the DSP I code. I remember some very picky standards about what to do with unexpected values for space computing. Pesky alpha/beta/gamma particles flipping RAM cells around and the like. I have fixed my share of mixed boolean true logics gone bad. Is it a one, -1 or non-zero? If true == mySupposedBool can be very tricky to find in C when mySupposedBool = -1 from some other language interface. At least false seems to always == 0. ----- I love standards, there is so many to choose from!
DSewhuk wrote:
If they had a default: case then I could almost see a reason. Consider the case if the bool was neither true or false. For most x86 C's there are 254 other trues and 65534 other trues on the DSP I code. I remember some very picky standards about what to do with unexpected values for space computing. Pesky alpha/beta/gamma particles flipping RAM cells around and the like.
Interesting; most programmers never have to consider the possibility of failure of the CPU/memory in their code. Does this imply that you must use a form of trinary logic (true / false / bad value) in such code?
DSewhuk wrote:
I have fixed my share of mixed boolean true logics gone bad. Is it a one, -1 or non-zero?
My problem is - how many compilers assume that a Boolean has only 'true' or 'false' values, ignoring the 'default' clause in this case? One solution would be to have your interface code treat 'Boolean' values as appropriate-size integers, converting to an appropriate type (e.g. true / false / bad value). This leads us to the logic above, where Boolean values are not truly Boolean. :)
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack. --Winston Churchill
-
Came across this kind of code today...
void EnableFromValue(bool enabled)
{
switch (enabled) {
case true:
FirstControl.Enabled = true;
SecondControl.Enabled = true;
...
break;
case false:
FirstControl.Enabled = false;
SecondControl.Enabled = false;
...
break;
}
}I'm sure there must be a better way ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
They forgot the
defaultclause! :wtf: :laugh:-- Kein Mitleid Für Die Mehrheit
-
If it is not break-en, don't switch it? [[Thank you, I'm here all week; try the veal...]] Chaos.
If you use "simple" booleans, that may be unnecessary. But what about "extended" booleans (i.e. true, false, don_t_know, FILE_NOT_FOUND)? That's where a switch statement comes in very handy.
-
Came across this kind of code today...
void EnableFromValue(bool enabled)
{
switch (enabled) {
case true:
FirstControl.Enabled = true;
SecondControl.Enabled = true;
...
break;
case false:
FirstControl.Enabled = false;
SecondControl.Enabled = false;
...
break;
}
}I'm sure there must be a better way ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
With "simple" booleans, a switch statement is not necessary. But what about "extended" boolenas (i.e. true, false, don_t_know, FILE_NOT_FOUND)? That's where a switch comes in very handy.
