• LCrawford (unregistered)

    In the frist place, shouldn't _done just be a public static export so that they can dispense with the pesky parenthesis and Is... prefix of IsDone()?

  • RLB (unregistered) in reply to LCrawford

    Of course not - that's not nearly Abstracted enough!

  • Dude (unregistered)

    Wait, someone actually fixed it? Does that make that TRWTF?

  • van Dartel (unregistered)

    IsDone is a private member and IsDone() is equivalent to _done (+ any change that could be made to the meaning of "doneness" would have to uphold this equivalence to make sense).

    So the trivial modification exposes a new anti-pattern which seems to be that variables are evil and should only be read via private functions (which by necessity must be exempted from this rule).

    Just get rid of either IsDone or _done.

  • (nodebb)

    Calling a private method which simply returns a private field is like hiring a head hunter to post a job ad in monster.

    Oh wait...

  • van Dartel (unregistered) in reply to van Dartel

    Correction after some over-analyzing: I just realized that if _done evolves from a boolean into eg a fraction (where, for example, 7/10 means 3 more steps to complete until achieving "done"), _done and IsDone() would not be remain equivalent and then the simultaneous presence of both _done and isDone could be defended better. I'd still not be persuaded by this example, but my arguments would be weaker.

  • ooOOooGa (unregistered) in reply to van Dartel

    There is also interface compatibility to consider. Keeping IsDone() around as a wrapper function is useless and redundant, true. Removing IsDone() means also going through all 829593215 places where it is used and changing them to use _done instead.

    That may be a job best left for another day.

  • (author) in reply to ooOOooGa

    Yeah, if the class were well written and followed the single-responsibility-principle even a bit, it'd probably be real easy to find/replace the private method invocations, but I deeply doubt that is the case. This is probably a single class for the whole UI, and not just one screen either, but like, a half dozen with a mode flag or something.

  • (nodebb)

    ZERO logic in the UI. All decisions made in testable classes that the UI is blissfully unaware of. The UI is nothing more (programmatically) than an exercise in "binding".

  • Some Ed (unregistered)

    I've certainly come across where people use the status text when there's an error code they could have just as easily used, and I agree, that is this WTF. There are times when I've found coworkers develop an internal API and they only have text errors, so the apps that use those APIs have to use those text errors. That's also this WTF.

    But there are also times where we're using a third party API that just does not do error codes. Maybe we've been forced to use this API because of a purchasing decision someone made without even considering the software (or despite considering the software.) Sometimes, the other products that somehow made it to the last round of evaluations managed to have even worse software, so this brain damaged API is the best of the lot, because it at least works in one language.

    If my memory serves me correctly, I've run into that situation twice in my professional career, and in one of those two cases, I was able to convince the vendor to add status codes, so we were able to fix our code to not depend on the text messages. In the other case, it was a proverbial tungsten pig that was bolted to the ground and someone in our finance department wisely chose to not pay for the amount needed to fly the pig.

    As such, I am not in the position of having to maintain such code now. But it still feels to me like, when you don't have a choice, it's somebody else's WTF, not yours.

    In the case of the tungsten pig, it was a really serious WTF, because not only did they have text only status messages, but in the locale of your choice (so long as you choose to be in one of the eight locales they supported. That's pretty much the whole world, right? The US, the UK, Germany, Australia, China, Japan, Brazil, and Uzbekistan. I mean, what else is there?

    In other news, I have some idea about where the development of that thing may have been outsourced to.

  • Some Ed (unregistered) in reply to van Dartel

    I'd tend to think making a change like that to _done would probably require making changes to most if not all of the things that use _done. Including this one.

    If you're on unix, the grep utility could be considered useful in locating these. If you're on Windows, I believe it's called find. If you're on Windows and you don't like the DOS command line, there's this thing called 'search' that most IDEs have.

    _done is not like done. I mean, it could be in a fair number of comments, but they're almost all talking about _done, and not about being finished with something. Admittedly, if _done is well named, there should be a fair amount of overlap between those two topics.

    Yes, I realize a lot of WTFs have been perpetrated by people who either do not know those tools, did not successfully use them, or did not finish going through their output (some could consider this not successfully using them, but others could consider it a separate case.)

  • Cheats Never Prosper (unregistered) in reply to Some Ed

    Outsourced to Elbonia, obviously, by Dilbert's boss.

  • MiserableOldGit (unregistered)

    Well it's the wrongiest way to do it, but if it just in some corporate app that isn't expected to deal with locales (yet) then it's just smelly ... trouble is you just know there's going to be far more stinky horrors lurking in less obvious places.

    A bit like when people get carried away using that tag property on controls to try create their own homebrewed XAML type thing. Kinda neat hack to start with, gets hard to handle quickly, and ends up being a huge tangled heap of flakey, brittle copypasta.

Leave a comment on “A Warning Label”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article