• (cs) in reply to Bill Brasky
    Anonymous:

    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....


    Maybe his ! key was broken.
  • (cs)

    I have code like this:


    myClass::setSomething() {

      m_flags = m_foo | 0x000c000e;

    }


    myClass::resetSomething() {

      m_flags = m_foo & 0xfffffffe;

    }


    In the class header there is an explination for all bits, which makes it clear why the reset doesn't clear all bits that the set sets.   This flag is rarely modified, normally it is read from hardware, and then latter written back out again, so not breaking all the bits out and latter re-combining them isn't an issue.


    With just a little bit of code that needs to be as above, seperate setBarTrue and setBarFalse makes sense, just to keep the code consistant.

  • (cs)

    Lamest WTF ever. Accessor methods/functions are used in a variety of languages for a variety of valid reasons. Assuming this is Java, maybe iOptBln is private and they want to be sure no one sets it to null.

  • (cs) in reply to gsmith
    gsmith:
    Lamest WTF ever. Accessor methods/functions are used in a variety of languages for a variety of valid reasons.


    And a small, but much more common number of bad reasons.

    gsmith:
    Assuming this is Java, maybe iOptBln is private and they want to be sure no one sets it to null.


    Assuming this is Java, a boolean is a primitive type and cannot be null.

  • (cs)

    This one got a bunch of WTF apologists right off the bat.  What is this world comming to, when bad code is explained away as "proper OO design" or "didn't want to update all the code"?  I'm ashamed of my professional brethren, I'm going off to make a quick buck now.

  • (cs) in reply to brazzy

    You got me on the second one, my bad. I'm not convinced its more likely that this is bad than good, though.

  • (cs)

    I had a mentor who would, as an exercise, take a spec document and transform it directly into the code, mostly by collapsing spaces and adding punctuation, plus some use of the preprocessor.  I could see a decent programmer prodcuing this code as the result of some process like that, either from a spec or from pseudo-code.

  • (cs) in reply to RevMike
    RevMike:
    I had a mentor who would, as an exercise, take a spec document and transform it directly into the code, mostly by collapsing spaces and adding punctuation, plus some use of the preprocessor.  I could see a decent programmer prodcuing this code as the result of some process like that, either from a spec or from pseudo-code.


    I really like the fact that this forum titles the discussion based on the title of the last post.
  • (cs)

    This is a poorly written accessor, and the whole point of an accessor is to future-proof for subclasses and requirements changes.  Consider if this is in a widely-distributed library, so the API becomes unchangeable.

    Later on you add an immitable subclass:

    public class ImmutableWTFClass extends WTFClass {
       public void setOptBlnToFalse() {
            throw new IllegalArgumentException(this+" is immutable");
       }
    }

    Next you add logging functionality:

       public void setOptBlnToFalse() {

            log("Set iOptBln to false");
            iOptBln = false;

       }

  • (cs) in reply to dleppik

    dleppik:
    This is a poorly written accessor, and the whole point of an accessor is to future-proof for subclasses and requirements changes.  Consider if this is in a widely-distributed library, so the API becomes unchangeable.

    Later on you add an immitable subclass:

    public class ImmutableWTFClass extends WTFClass {
       public void setOptBlnToFalse() {
            throw new IllegalArgumentException(this+" is immutable");
       }
    }

    Next you add logging functionality:

       public void setOptBlnToFalse() {
            log("Set iOptBln to false");
            iOptBln = false;
       }

    An Immutable subclass is a WTF in itself, it should be the other way around if you want to preserve the Liskov substitution principle. Though I have done this in the past... [:$]

  • (cs) in reply to mjonhanson
    mjonhanson:
    This one got a bunch of WTF apologists right off the bat.  What is this world comming to, when bad code is explained away as "proper OO design" or "didn't want to update all the code"?

    You may give a try at the concepts of "irony" or "sarcasm"

  • (cs) in reply to RevMike

    Only if people click the appropriate reply button.


    BTW the captcha image doesn't show anymore

  • (cs) in reply to dhromed

    dhromed:
    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".

    This is simply an example, in reality this was done for all sorts of one line expressions and the name changes from place to place. Also sometimes CheckIsNull does not just check if it is null but also if it is an empty string. Every class you need to check the semantics of the method while reading a block of code.

    It actually kind of reminds me about the ways operator overloading and C macros can be misused to obfuscate code.

  • (cs) in reply to Taevin
    Taevin:
    ... lame.  And if you're going to use the bastardized version of Hungarian notation, why would you use i for a boolean?


    Due to Symbian variable naming conventions. Variables defined as part of a class always have names beginning with i.
  • (cs) in reply to jean9
    jean9:
    Taevin:
    ... lame.  And if you're going to use the bastardized version of Hungarian notation, why would you use i for a boolean?


    Due to Symbian variable naming conventions. Variables defined as part of a class always have names beginning with i.


    'i' for instance?  Sorta kinda makes some sense - not that I am endorsing it.  How are class/static variables annotated?
  • (cs) in reply to RevMike
    RevMike:
    jean9:
    Taevin:
    ... lame.  And if you're going to use the bastardized version of Hungarian notation, why would you use i for a boolean?


    Due to Symbian variable naming conventions. Variables defined as part of a class always have names beginning with i.


    'i' for instance?  Sorta kinda makes some sense - not that I am endorsing it.  How are class/static variables annotated?

    Member variables' names begin with "i". Arguments' names begin with "a". Local and static variables' names have no initial letter. Global variables are usually avoided, but when used, their names begin with a capital letter (global variables cause problems when compiling dll's). Constants' names begin with "K".

    Then there is own naming conventions for class names: C for heap-allocated classes, that are derived from Symbian's base class CBase (C classes have to implement Symbian's own two-phased construction). T for value classes and datatypes. R for resource classes (contains a handle to resource which is maintained elsewhere). M for abstract interface classes.

    Structs are considered similiar to T classes and since enumerations are types, they have also the T prefix (but enumeration members have prefix E).

    Symbian does not use Hungarian or any notation which attempts to include the variable type in its name.

    As some of you may think now, Symbian itself is quite wtf... ;)

  • (cs) in reply to Nand
    Nand:

    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*


    even so - you could always provide the two callback functions as wrappers around the generic setOptBln(bool) one... that way all your normal code uses the generic one and it's only the callbacks that are wierd... not that I'm endorsing actually doing that.

  • tfarker (unregistered)

    Here's my problem: sigother found CC bill with huge charges to "restaurants" that are really strip clubs. Do I tell him the that I habitually spend $3000/week at the club or lie and say it's all a BIG MISUNDERSTANDING? Damn. Whaddya do in this situation? Difficulty: there are 3 kids between us and he's left the house (and them; I'm with the kids) after packing.

  • ANON (unregistered) in reply to tfarker

    You're fucked.

  • (cs) in reply to tfarker

    Anonymous:
    Here's my problem: sigother found CC bill with huge charges to "restaurants" that are really strip clubs. Do I tell him the that I habitually spend $3000/week at the club or lie and say it's all a BIG MISUNDERSTANDING? Damn. Whaddya do in this situation? Difficulty: there are 3 kids between us and he's left the house (and them; I'm with the kids) after packing.

     

    uh..... wtF?

  • James Sweet (unregistered) in reply to Mr. Big

    Dunno why I'm commenting on a 4+ year old post, but anyway...

    It's quite possible this is an artifact leftover from when there used to be some kind of complicated side-effects or something that made it make sense.

    I have a function in a system I am delivering that, ripping out the comments, is something like this:

    Date parseDate( String dateString ) {
      return new Date( Long.parseLong(dateString) );
}

    That's because parseDate USED TO create multiple DateFormat instances for different possible formats, attempt to parse them in try-catch blocks, falling back to the next DateFormat if it failed.... until the protocol got changed to just use milliseconds-since-epoch. Now I've got this really stupid pointless function sitting there.

Leave a comment on “Functionally Illogical”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article