Switch boolean.... (reinventing if, unnecessarily)
-
Umm...that's not true. 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.) On the other hand, if/else statements do bail as soon as the first passing conditional is found and the associated code block is executed.
Scott E. Corbett
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
-
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.
Totally agree.
Jeremy Falcon
-
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.
Couldn't resist:
void EnableFromValue(bool enabled)
{
FirstControl.Enabled = enabled;
SecondControl.Enabled = enabled;
...
} -
Umm...that's not true. 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.) On the other hand, if/else statements do bail as soon as the first passing conditional is found and the associated code block is executed.
Scott E. Corbett
I believe a switch is just a calculated jump statement. It doesn't work it's way through all the previous possibilities. Yes. Once calculated, the program goes to the break statement then jumps out appropriately. Switch statements are quite fast. In this case, I don't see advantage either way as an if statement is very simple too.
-
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.
it is simple : void EnableFromValue(bool ?enabled) { FirstControl.Enabled=enabled.HasValue?enabled.Value:false; SecondControl.Enabled=enabled.HasValue?enabled.Value:false; }
-
it is simple : void EnableFromValue(bool ?enabled) { FirstControl.Enabled=enabled.HasValue?enabled.Value:false; SecondControl.Enabled=enabled.HasValue?enabled.Value:false; }
This works for me FirstControl.Enabled = SecondControl.Enabled = (enabled) ? false : true;
-
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.
I have code like that. It is the "..." that is significant. For some objects, you can't just set enable = false, you have to do other things. And, in some cases, one switch branch will enable some fields and disable others.
-
So better way is this?
FirstControl.Enabled = enabled;
SecondControl.Enabled = enabled;or better yet, MVVM would help if applicable to the app.
I have code like that, but sometimes it is not so simple. Not all objects have an "enabled" property, and sometimes I may need to enable some and disable others. Keeping the switch, or at least an "if ... else" structure, makes for more clarity, just in case these oddball things are necessary.
-
This works for me FirstControl.Enabled = SecondControl.Enabled = (enabled) ? false : true;
LOL! I recently went through my company's entire code base to purge out constructs such as "? true : false". Even more fun were comparisons such as "if (some_int_var == TRUE)". That's great unless, say "TRUE" is defined as 1 and your variable is set to -1.
-
I have code like that. It is the "..." that is significant. For some objects, you can't just set enable = false, you have to do other things. And, in some cases, one switch branch will enable some fields and disable others.
-
LOL! I recently went through my company's entire code base to purge out constructs such as "? true : false". Even more fun were comparisons such as "if (some_int_var == TRUE)". That's great unless, say "TRUE" is defined as 1 and your variable is set to -1.
Look. this construct is a perfect alternating on/off switch. I've used it exclusively over past 10 years. There is no valid reason not to use it, especially if you favor Clean, concise, easy to understand code. Different strokes ... Tony d
-
Look. this construct is a perfect alternating on/off switch. I've used it exclusively over past 10 years. There is no valid reason not to use it, especially if you favor Clean, concise, easy to understand code. Different strokes ... Tony d
-
No, "? false : true" is still superfluous. Just use ! (the not operator). It's certainly more concise, and I would argue, even cleaner and easier to understand. FirstControl.Enabled = SecondControl.Enabled = !enabled;
Hey Dan love the use of Boolean operators. Used them extensively in the old mainframe days when storage was measured in megabytes. When working with 16mb system storage every byte counted. Here's an old trick to save bytes a *-6, ctr. Used this in 360/370 mainframes since adding the opcode (numeric value of 1) would save 1 byte. nice chatting with a knowledgeable tech
-
So better way is this?
FirstControl.Enabled = enabled;
SecondControl.Enabled = enabled;or better yet, MVVM would help if applicable to the app.
FirstControl.Enabled = SecondControl.Enabled = enabled;
-
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 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: -
Umm...that's not true. 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.) On the other hand, if/else statements do bail as soon as the first passing conditional is found and the associated code block is executed.
Scott E. Corbett
Well I kind of assumed you knew how to write a switch.
-
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
