- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- 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
Did it blow up?
Were they functions on public class Pandora?
Admin
I'm not suggesting it really justifies it, but it's possible that the name was intended for anyone changing the method rather than calling it. Every so often it's handy (though really ugly) to have a dummy parameter for the sake of distinguishing calls from an overloading point of view. In that situation, you don't want the called method to use the parameter at all, because you don't know what people might have supplied when it genuinely wasn't being used.
Just a thought.
Admin
Or it could have been a method in a class that is serialized, that required an Object-variable to be sent in at first, but which later on got unnecessary. If you change the "layout" of the method, all the objects that has been serialized will become invalid (unless you code around it), and so, doing like this could just be the lazy mans way of getting around a change in a Serialized class.
Admin
There's a bunch of this in the native DirectShow API - probably in MFC too I shouldn't wonder, but life's too short to go and find out.
Admin
And this, ladies and gentlemen, is why you should never use built-in serialization to write into persistent memory. You never know what can of worms you are creating for the future maintaners of your code.
Admin
Wow! That's so cute... it brings a smile to my eyes.
Admin
I'm more amazed by the fact there was documentation
Admin
This is like God tempting Adam with the forbidden fruit. Well sorta. If God was a crappy coder.
Admin
Admin
So not exactly a happy day then.
Admin
Did anybody ever consider that the name of the parameter means to not use the function? It's possible that the intention was to warn that the function was deprecated, or something to that effect. In fact, I imagine we would have all caught on to it, if not for the summary and title "The Forbidden Parameter".
Admin
Could be some sort of recursive function thing. IOW do not use this parm for the initial call or something (but subsequent calls need to pass an instance of itself etc etc).
Nice descriptive naming too... you could also call it the "shinyRedHistoryEraserButton" parm.
Admin
But then it should be two functions - one for the public interface and one private function that recurses.
I'm not saying you're wrong, all I say is: Even if you're right, it's still a WTF...
Admin
What an obvious way to declare something deprecated. Anyone would be stupid not to realize it.
In other news: July 4th is "Ulrichstag", Wikipedia told me. On that day, people (mostly in the Alps) bless everything around them to protect it against bad weather.
Admin
It's probably a parameter to make the function behave in a slightly different way, used by some other module, that has internal knowledge about this function, but is not in the same assembly/namespace and thus can't be made internal. Your typical implementation dependence coupling, in other words, with a developer too short on time or give-a-dams to factor and document it better,
Admin
If you pass something as that object, it likely throws a OMFG_I_TOLD_YOU_NOT_TO_USE_IT exception.
Admin
Admin
Damn, this "worse than failure" is super lame. It doesn't even... go into an explanation why the parameter is there, that might have been interesting
Admin
I think it's a wtf because we don't know >_>
Admin
The real WTF is that there wasn't a comment explaining the cutesy parameter name. Why play games instead of a simple comment inside the function?
Another argument for code reviews. A second pair of eyes would have hopefully kept this out of production.
Captcha: kungfu
Admin
Ummm, god WAS a crappy coder!
Let's see, where to start... Vote for your favorite!
(code reuse)
(scalability) 3. Antivirus software without automatic updates?! At least it doesn't slow down the system when there is no active infection...
(extensibility) 4. There's no easy way to use any plug-ins (wings, gills...)
(maintainability) 5. It's really hard to replace malfunctioning/broken modules (organs)
(dead code) 6. Look at all the junk DNA!
(happy path) 8. Most (if not all) pleasurable/indulgent activities eventually result in unstable system?!
Debugger & source code do not come bundled with the system?!
Maximum average uptime of only 70-90 years, highly dependent on external factors?!
the list goes on...
Admin
Come on, the real WTF is that nobody can use the call. I'm thinking what they really wanted was:
public object LoadOrg(int cmpKey, object DO_NOT_USE_AT_ALL_EVER_UNLESS_YOU_ARE_AT_LEAST_SENIOR_SOFTWARE_ENGINEER_LEVEL_5);
Admin
Y'know, it is legal to use different names for different methods.
Admin
...or, you could do what a competent developer would do: change the serialVersionUID and modify the deserializer to recognize and handle both versions.
Admin
@deprecated? private? protected? package?
Admin