|
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
|
|
|
|
|
I see a reason for the function but not for the switch statement. Except if you are paid by lines of code of course. 
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Totally agree.
Jeremy Falcon
|
|
|
|
|
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 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.
|
|
|
|
|
#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
|
|
|
|
|
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
|
|
|
|
|
This happens to me sometimes, until I get a few lines into and realize that there is a much simpler way. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
So better way is this?
FirstControl.Enabled = enabled;
SecondControl.Enabled = enabled;
or better yet, MVVM would help if applicable to the app.
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
FirstControl.Enabled = SecondControl.Enabled = enabled;
|
|
|
|
|
At least, his casing is ok.
while (true) {
continue;
}
|
|
|
|
|
Thanks for posting! After two weeks without a new thread, I was starting to think that we are all working on perfect code! BTW, the example is perfect for getting your LOC up! 
"Go forth into the source" - Neal Morse
|
|
|
|
|
You aren't working with my previous employer, are you?
|
|
|
|
|
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.
|
|
|
|
|
Or take it out altogether as it's setting 2 Booleans.
|
|
|
|
|
In that case it has the same advantage as the "if" would have; but if that is an important 'optimization', then you already have a bigger problem 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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. 
|
|
|
|
|
Probably because it is a micro-optimization; you won't notice much difference if it merely saves you the toggeling of a boolean.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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. 
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
