Switch boolean.... (reinventing if, unnecessarily)
-
That's the gist of it yep. This is in an MVVM app, using a framework I architected. Sadly, one of the dev's has a habit of naming View Model fields too literally after the thing in the View, so it still ends up looking like code manipulating the view directly (and at the other extreme, a hell of a lot of business logic has polluted the view model). So, while the controls may not be called "FirstControl" etc., its really not that far off - properties with names like "CustomerListBoxSelectedCustomer". I try to clear up as much as I can as I work with stuff, but it seems some people just don't want to learn to work with architecture.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Someone needs to sit down with the guy and give him some 'help' to understand decent coding practices. Keep a hammer ready ...
My plan is to live forever ... so far so good
-
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.
You aren't working with my previous employer, are you? :laugh:
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I voted this a 5 because it was funny, but I could see a valid reason for that... if they wanted to encapsulate the logic of which controls were affected into a single resource I could see me doing that. Especially if it's called in more than one area.
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.
The advantage of a switch is that it bails as soon as a test passes, thus reducing conditional branching. Here you could use an if else.
-
The advantage of a switch is that it bails as soon as a test passes, thus reducing conditional branching. Here you could use an if else.
-
The advantage of a switch is that it bails as soon as a test passes, thus reducing conditional branching. Here you could use an if else.
-
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.
-
In my experience Microsoft is pretty much immune to optimisation. You can reduce branching by one or two orders of magnitude and the crappy performance just doesn't budge. :zzz:
-
The only reason I could think for writing or keeping the code this way would be if enabled became an enumerated type and had more than 2 states.
In that case - create it as an enumerated type, with two values. You may then expand the enumeration without rewriting the existing code.
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
-
In my experience Microsoft is pretty much immune to optimisation. You can reduce branching by one or two orders of magnitude and the crappy performance just doesn't budge. :zzz:
-
Ha! It was actually an image processing filter mask which used pointer arithmetic. I invented something I called a Summation Threshold Filter which should have been ten times quicker than a Median filter. Let's just say that this was not apparent. :laugh:
-
The advantage of a switch is that it bails as soon as a test passes, thus reducing conditional branching. Here you could use an if else.
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
-
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.
FirstControl.Enabled = !FirstControl.Enabled;
SecondControl.Enabled = !SecondControl.Enabled; -
That's the gist of it yep. This is in an MVVM app, using a framework I architected. Sadly, one of the dev's has a habit of naming View Model fields too literally after the thing in the View, so it still ends up looking like code manipulating the view directly (and at the other extreme, a hell of a lot of business logic has polluted the view model). So, while the controls may not be called "FirstControl" etc., its really not that far off - properties with names like "CustomerListBoxSelectedCustomer". I try to clear up as much as I can as I work with stuff, but it seems some people just don't want to learn to work with architecture.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Code Reviews Code Reviews Code Reviews Here is a great rule. When someone gets multiple "mandatory" changes needing to be made as a result of a Code Review. Then you must review weekly, ALL of their code. This continues until they no longer require "mandatory" changes for a few weeks in a row. The goals are: 1) Slow them down 2) Get them to proactively ask people how they should code/name something 3) Show them the right way (for your group) to do things Our Code Reviews have 3 Comment Levels: - Mandatory: We will not let this stand in production, must be rewritten - Suggested: We are not thrilled, but if you can "really" defend it. - Noted: We are just making a note, take it or leave it (Variable names, Variable comments) Make Code Reviews fun. Friday starting at lunch time with pizza brought in. It helps you to detach from the depth of coding for the weekend. Besides, Code Reviews are how Good Developers help new Developers!
-
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;
