The dev was fired but the havoc is left for us to fix...
-
[rant] If forecolor red then disable(control) else if forecolor black then enable(control) [/rant] :mad::mad::mad:
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
Well, I had the same, but the color was PapayaWhip... :(
-
The most annoying thing about cr@ppy code like that is that it usually works. Any self-respecting computer should billow forth plumes of black smoke on meeting such drivel.
I wanna be a eunuchs developer! Pass me a bread knife!
Works... well more like touch and go... as in touch the color in the themes and there goes the functionality
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
-
[rant] If forecolor red then disable(control) else if forecolor black then enable(control) [/rant] :mad::mad::mad:
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
lol, if it works, it works. If you're alone on the project, and get fired, your replacements deserve to go through hell.
-
[rant] If forecolor red then disable(control) else if forecolor black then enable(control) [/rant] :mad::mad::mad:
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
My favourite was "delete this" in a class destructor. Hours of ROFL on that one.
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
-
[rant] If forecolor red then disable(control) else if forecolor black then enable(control) [/rant] :mad::mad::mad:
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
-
Color-blind users need not apply... It seems that just introducing constants for the colors could help with readability. public const Color NotApplicable = Color.Red but I am pretty sure that this one liner just scrapes the surface.
It is beyond that. Who bases control state based upon its adjacent text color?????
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
-
"If forecolor red then disable(control) else if forecolor black then enable(control)" Oooh sounds like a system I had to suffer/work on; not the Credit Derivative VB code at a certain north American bank?! Except, that used colour to denote state, so the controls could be any one of about 6 different colours...
Nope not even close.
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
-
lol, if it works, it works. If you're alone on the project, and get fired, your replacements deserve to go through hell.
Ah, so it WAS you!
-
It is beyond that. Who bases control state based upon its adjacent text color?????
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
-
It is beyond that. Who bases control state based upon its adjacent text color?????
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
I'm sure I'll take heat for this but, honestly, I don't think it's that bad. One boolean is (almost) as good as another. Without seeing the rest of the code, it's hard to tell what the intention was. Certainly I would try not to do this but perhaps the developer was attempting to avoid a global variable to hold control state? Or perhaps there are a number of controls who's state has to be managed and the dev wanted to avoid an array or a hash? Perhaps the control state is set from a disconnected object and there is no mechanism to transfer state? I dunno? But it's pretty common to do things like if $('#myid').hasClass('enabled') { // do something }. Other than string processsing to get a boolean, it doesn't seem that far different to me. shrug.
-
I'm sure I'll take heat for this but, honestly, I don't think it's that bad. One boolean is (almost) as good as another. Without seeing the rest of the code, it's hard to tell what the intention was. Certainly I would try not to do this but perhaps the developer was attempting to avoid a global variable to hold control state? Or perhaps there are a number of controls who's state has to be managed and the dev wanted to avoid an array or a hash? Perhaps the control state is set from a disconnected object and there is no mechanism to transfer state? I dunno? But it's pretty common to do things like if $('#myid').hasClass('enabled') { // do something }. Other than string processsing to get a boolean, it doesn't seem that far different to me. shrug.
Here's the thing though: it's not obvious to some future developer why all of a sudden the control is disabled or enabled. When Alberto finds this, it's still not obvious. If you had something like: if (someBadCondition) { disableControl(); setTextRed(); } [one might abstract more, but you get the idea], then the intention of the developer is exposed. Also, as others have mentioned, it's far too easy to introduce unintentional side-effects: "Oh, you want the red to change to blue? Coming right up..." because new developer doesn't realize that (en)disability of said control is dependent on color (why would it be?). @Alberto: on the plus side, at least your organization got the first part right: you fired the dev.
-
It is beyond that. Who bases control state based upon its adjacent text color?????
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
-
Here's the thing though: it's not obvious to some future developer why all of a sudden the control is disabled or enabled. When Alberto finds this, it's still not obvious. If you had something like: if (someBadCondition) { disableControl(); setTextRed(); } [one might abstract more, but you get the idea], then the intention of the developer is exposed. Also, as others have mentioned, it's far too easy to introduce unintentional side-effects: "Oh, you want the red to change to blue? Coming right up..." because new developer doesn't realize that (en)disability of said control is dependent on color (why would it be?). @Alberto: on the plus side, at least your organization got the first part right: you fired the dev.
Yes, the unintentional side-effect is definitely an issue. I guess I'm just being magnamous today but I would want to see more of the code before I fired the developer over it. :-D
-
[rant] If forecolor red then disable(control) else if forecolor black then enable(control) [/rant] :mad::mad::mad:
Alberto Bar-Noy --------------- “The city’s central computer told you? R2D2, you know better than to trust a strange computer!” (C3PO)
It is strange, and something I would never do. However, without knowing the full context I can see that it might be somewhat logical. For example, if a variable was used to store the state (instead of the color) and the color was required to be changed at the same time, you could argue the variable is redundant and why not just use the color. Particularly if it is a small piece of self contained code that has no coupling or external influence. In that case, who cares, if it works move on.