- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
He is just abstracting out this process. Who knows, in the future he may want to change 'false' to 'fileNotFound'
Admin
omg, what vile creature posted my proprietary code to this site???
HOW AM I SUPPOSED TO CHARGE $200/HR WHEN YOU AMATEURS KEEP STEALING MY ELITE WORKS OF ART???111!!!
Be advised you should expect a call from my lawyer soon. His name is Leonard "J." Crabs, and his legal acumen is feared far and wide.
vc
Admin
I'm sure this was an update to a program that had much more complicated methods for setting a variable to true or false and to update all references to the call would have been more difficult than leaving the code as is.
Admin
Isn't the Standard Definition of "true" still in committee?
In his defense: Could these be "setters" from a class? I once had a university-level instructor that taught this as the proper way to practice "data-hiding," "abstraction," etc.
brillant!
Admin
I could use methods like this in my work. I hate typing out that damn equals sign all the time. Mind if I borrow?
Admin
You don't know anything Alex, it's clear that THIS is OO programming at it's finest: the data is completely abstracted, be it the one inside the object itself or the one transfered between the object and the outer world, and only messages are passed around.
Here, you see a true separation between the object's interface and it's implementation, without all this cluncky parameter passing or *shiver* public variables.
Admin
Look at the function names. Set boolean to true. Set boolean to false. Theres only so much that they can do...
Admin
I could understand using setOptBln() if you want to have setters for everything, and add security checks to just the setters that need them. ToFalse() and ToTrue(), however, is indefensible.
I agree with a comment that was made at JavaWorld:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox-p3.html?post=16482#talkback
"<font face="verdana, arial, helvetica" size="3"><font class="post">Frankly I prefer the approach taken by some other languages: you define a public field, where getter and setter methods can be transparently added latter. In other words, dealing with the field will call the methods if they exist, or hit the field directly if they don't. This seems preferable to wearing your hands out (or buying a fancy IDE) to generate a lot of makework text in your source code."
</font></font>
Admin
this is a pretty weak WTF without knowing the context of how it's used
Admin
Getters and setters are usually a good idea but having a separate setter for each value is stupid. A better setter would be:
public void SetOptBln(bool Value)
{
iOptBln = Value;
}
The real WTF I think is the tragic effect two setters would have on any sort of programmatic code. Instead of something relatively nice and logical like SetOptBln(SomeFunctionThatReturnsABool()); you'd get something like:
if(SomeFunctionThatReturnsABool())
{
SetOptBlnToTrue();
}
else
{
SetOptBlnToFalse();
}
... lame. And if you're going to use the bastardized version of Hungarian notation, why would you use i for a boolean?
Admin
I'm not sure I can agree with that. It may not be eye wateringly bad (but some other forum members will disagree with even that), but it does violate the fundamental idea of procedural (forget OO, procedural) programming that most everyone here is familiar with. You would't even pull this in COBOL, where passing parameters to subroutines isn't the way the language is designed to operate. [Disclaimer: I haven't worked with COBOL since using compilers for the '85 and '90 standards, so I don't know what the 2000 spec has done].
Admin
Agreed. New to posting here, can't figure out the emoticons, and I forgot my <sarcasm> tags. FTR, although that instructor felt that this level of abstraction was a Good Thing™, I do not, and we had many ... animated ... discussions on the topic.
See above.
No clue ...
Admin
Can you think of ANY way to use it?
Admin
Ask and ye shall receive. Imagine you're taking your first OO programming class and the teacher tells you to never make any of the member variables public, instead make public functions that, when called, will modify the object's private variables. Maybe he wanted to set up some kind of event processing so that when the boolean value was changed, other code will be called to change something on a form, or update a database value.
It could have been a test project by this newbie programmer, or maybe development code that was just a placeholder and hadn't been fully worked on yet. Until someone can give some more details, I'd say it's hardly a WTF, more like a "Hrm I suppose that's one way you could do it".
Admin
Isn't it obvious? the initial value of iOptBoolean is fileNotFound. With these handy-dandy encapsulators, he can tell if one of them was called because iOptBoolean would have a value of true or false. This paves the way for:
public bool isOptBooleanSet() {
if ((iOptBoolean == true) || (iOptBoolean==false)) return true;
else return false;
} [:P] or better yet a switch statement...
Admin
I'd like to see a version that sets a property to some arbitrary character, rather than 1 or 2 possible values
Admin
Actually, add comments to the equation and this actually does save time.
Admin
ITYM "I suppose that's the worst possible way to do it."
ok
dpm
Admin
'i' for information.
And information in it's purest, simplest form is a single bit - true or false. This is descriptive programming at its best.
Similarly: loiialName = 'Fred'
loiial = lots of information in a line. More descriptive, and less ambiguous (is that a word, or an instance of a Twine object?) than the word String.
Admin
I just hope this guy will never ever create a class with an integer field. Just imagine it...
setIntToZero()
setIntToOne()
setIntToTwo()
...
Admin
No, I'm pretty sure I had it right the first time, but I appreciate your editorial skills.
Is it a horribly overblown obfuscated implementation of a fairly simple action? I've seen some hellish functions to do something as simple as return the integer portion of a float (which I hear they make built-in functions for nowadays), so something like this seems like a silly way for a newbie to interact with private members of a class.
Is it wrong? Not really. Is there a better way? You bet. Will this guy eventually learn when he moves on to his second C++ class? Let's hope so.
Admin
Have you deeply thought about this?
Good, now try to apprehend what a class with multiple string fields would involve.
Admin
But the point is, code that's posted here supposedly is all from production code. This isn't some kiddie taking his first steps in Java (yes, Java, not C++), this code is actually out there!
Admin
This code is in use somewhere?!?! OMG teh system is br0kun!!!one
So the argument is that this code results in an increased number of keystrokes to set a boolean variable? Seriously? Aside from creating two functions that each perform a single action, I hardly see what's so awe-inspiring about this bit o' code. A better WTF would be if it took some obscure parameter like a string or integer, and did some kind of crazy "new" math to turn it into a boolean.
At its worst, this should be reduced to one function that takes a boolean parameter, but I never advocate allowing other parts of code to directly interact with my variables. If someone else's code changes a "true" to a "false" when I don't expect it, there could be some interesting results.
Admin
This functions has a horrible bug...
It doesn't check for isTrue(iOptBln) before assignment!
Admin
sure you mean like the one found in
AppDomainSetup.ShadowCopyFiles
http://blogs.msdn.com/brada/archive/2005/11/17/494282.aspx
Admin
I don't regard this as a WTF at all. Having methods with one line to set a value is normal in Java. I'd be surprised if a large Java project didn't have methods like this. Other than reflection there is no other easy way for classes to set/get private values within other classes.
The guy submitted this clearly has very little experience with Java. I'd be interested to know what his "better" alternative would be to allow other classes to set iOptBln.
Having said that, there is one minor WTF and that's why they didn't use:
public void setOptBln(boolean value) {
iOptBln = value;
}
Having a set method for each value that can be set on a variable is inefficient, hard to maintain and, for anything that's not a boolean, incredibly time consuming.
Admin
You consider converting the string "true" to the boolean "true" to be obscure? They're spelled almost exactly the same, if you'll notice...
But yeah, that's the right idea. M$ is a WTF factory, and they're always working overtime.
Admin
This isn't too bad. A coworker of mine told a story of old co-worker who perferred:
public class Foo {Invaribly, he'd eventually mess up one of his setters, or update the values without the setter inside the class and break his code. Nobody could ever figure out why he did it the way he did....
Admin
That's some damn fine quote here, would you allow me to re-use it?
Admin
I (your name) __Manni__ do hereby entrust unto (recipient name) __masklinn__ exclusive rights forthwith to reuse, modify, or alter the aforementioned phrase until such time that the phrase is no longer deemed valid upon the utter destruction of the corporation mentioned, or until (your name) __Manni__ goes flat broke and will require royalties for the use of said phrase.
Admin
Two reasons.
1) Because there should be no bias.
2) So that he could always use a positive test without having to think to hard...
A nice, easy
if (notSomething) // aaah, so nice
rather than the complicated, difficult-to-understand
if (!something) // shudder
Admin
Apart from the "getter/setter" idiom being basically a way to subvert the OO paradigm by making C-style structs look vaguely OO, it is IMO WTF-worthy for managing to write a method whose name is neither shorter nor more descriptive than the code it contains.
I can imagine cases where I'd write parameterless methods that set a field to a specific value, but only in order to use a more descriptive name for and operation that shouldn't really be considered a "setter".
Admin
Ahh, obviously the epitome of Zen Programing. Keep an lookout for other classes like:
public class OneHandClapping{
}
public class AskTheBuddha{
}
They all inherit from:
public class Koan{
]
Admin
If this were C/C++ the reason would be clear:
imagine you have some framework that takes a callback of type void (*some_type)() and you want the callback to set your (ahem) global or file level static variable iOptB1n to true or false. Problem solved!
Hmm... I guess you could do it in C# too.
Great variable name, by the way. Naturally, you have to remove other letters to make room for the hungarian notation. Let's not mention the fact that the standard hungarian notation dictates that iOptB1n should be an integer...
Admin
Neither of these is an excuse for not doing
public void setOptBln(boolean value) {
iOptBln = value;
}
In the latter case, you might have
public void setOptBln(boolean value) {
iOptBln = value;
if(value) /* do stuff for true */ else /* do stuff for false */
}
Admin
Oh, there are much worse ways to do this. At least this one doesn't contain any logic errors; I could easily see a copy+paste programmer doing
Admin
Not really. You can make that mistake, but you can also do it correctly - make the variables private, and put wrapper logic in the getter/setter functions when needed.
As for eliminating getter/setter in favor of DrawYourself(), RenderYourselfAsHTML(), etc., that's a separate and more complex topic and I don't have the practical experience to have a useful opinion on it.
Admin
Where are the comments here? I mean, how can one possibly look at this heavy, thick snippet of code and figure out what it does? How can the programmer possibly assume that anyone can understand his sophisticated, elegant program without adding comments? That's the real WTF here. I would have added the following comments for the average programmer to better understand this procedure:
public void setOptBlnToFalse() //public is used to make a method less private
{ //the curly brace pointing to the right opens up this bag of fun
iOptBln = false; //the = sign assigns the second thingy to the first thingy
} //the curly brace pointing to the left closes up this box of amusement
//the space makes it easier for us to know the second part of the stuff is not the same as the first
public void setOptBlnToTrue() //public does not mean government-owned
{ //could I have used # instead of { ? I'm not too good with programming
iOptBln = true; //what am I doing again?
} //OK, this means I'm finished. Time to catch the short bus back home.
/* ED: ... */
Admin
To give the benefit of the doubt:
It's possible that initially there was only a setToTrue method and no setToFalse method. i.e. The public interface of the class only allowed users to set the flag, but not to clear it. Later on, the contract/spec changed and the setToFalse method was added. I could think of a few other examples that would at least partially explain it.
Even if that's not the case (and I assume it's not), IMHO it's not a WTF. To qualify as a WTF, seeing the code has to make you laugh hysterically or break down in tears. This code is amateurish, but is not a great WTF example.
Admin
One, (weak), if performance was ultra-critical on this particular code. setOpt(val) has to load a register with a particular value before the subroutine jump (and possibly save the previous register contents first), then copy that register to the address within the subroutine; setOptVal() just has to do the subroutine jump, then set the address with an absolute value within the subroutine.
Two, if the general context of the code showed plenty of examples where set(true) and set(false) performed radically different things (well, in addition to setting the actual value), and if/else was impractical (let's say for the sake of argument they're each a couple pages long, and you don't want an else clause that far separated from the if). Then, consistency might push for separating the set(true) and set(false) functions into setTrue() and setFalse() in this instance as well.
The sample code is definitely a "Huh?" but it certainly doesn't make me sit here and go "WTF".
Update: Since I composed the above comment, a couple others have suggested other viable reasons for doing something like this (e.g. initially, foreign code could set but not reset the value (or vice versa). I, on the other hand, was restrained from posting my invaluable insights because, after all this time of being "caught by the captcha", tonight the captcha image disappeared! Yup, instead of being told you're wrong the first time, you had to simply guess at what the captcha might be from seeing the "broken image" icon. And thus is formed the history of my login id, as I finally had to register to post anonymously. Now that makes me go "WTF" :)
Admin
What's in a name?
iOptionalBoolean?
iOperationalBoolean?
InputOutputPhysicalTortureBoolean?
iOptionBoolean?
What does it all mean??
Drak
Admin
Perhaps once upon a time the iOptBln field was an int (it starts with an i! an i!), and then setting it to false meant setting it to -1 or something, and setting it to true meant the value was computed by some unholy means.
We JUST DON'T KNOW!
Admin
Good OOP. Nothing bad about it. However, the names are not well choosen. Should have been:
public void enableOptBln() { ... }public void disableOptBln() { ... }Admin
The first is just a way of fooling yourself into thinking you're being OO, while the second is rarely done at all. I'd estimate that upwards of 90% of all getters and setters that get written contain no logic whatsoever.
A shame, because that's what OO is all about. If you're creating "value objects" and pass them to methods that get those values with getters to do the actual work, you're NOT doing object oriented programming! Sure, sometimes there are good reasons not to be religious about it, but most of the time the reason is simply a lack of proficiency in "OO thinking".
Admin
I had a women working on my team who graduated from a CS course as a mature student (15 years from retirement age) and she insisted on writing code like this. During code reviews I would regularly come across code like:
private bool CheckIsNull(object o)
{
if (o == null)
return true;
else
return false;
}
She couldn't understand how less readable this made her code.
Admin
There are languages that don't have "!" (or provide alternatives to it, cf Ruby where
!aandnot ahave the same meaning), so the aforementioned code would look likeRather than the complicated, difficult to understand
Admin
Maybe the code has to be used with some kind of framework that wants callback function pointers for various events. When you have pointers to a function(void), you have to embedd the "parameters" into the body of the function.
That's my guess anyways, that those functions were hooked up to a GUI that only lets you call methods without parameters.
*shrug*
Admin
Well, it doesn't make it less readable -- especially after you're used to seeing "CheckIsNull(someObj)" everywhere.
It doesn't increase readability either. It really has no effect on readability any way you put it at all. However, I think that there is a slightly higher chance of bracket nest confusion, compared to "someObj == null".
Admin
On the plus side, it certainly increases code readability, assuming you prefer your code to read more like english than C-ish.
Kinda makes you hope for inline compiling tho huh? Does anyone else think this guy could write hello world and get a stack overflow??