• Dale (unregistered)

    JimM, Thanks, that makes perfect sense.

  • sf (unregistered)

    Another WTF is the stupid Microsoft practice of prefixing interfaces with "I". I hate that crap.

  • GF (unregistered) in reply to Ben
    Ben:
    I think it's good for people to know the difference. In some of the code I maintain, I've sometimes seen i.e. and e.g. used incorrectly in such a way that complicates what the writer was trying to say.
    Whoah, you have a compiler that understand Latin? Sweeeet....
  • GF (unregistered) in reply to mathew
    mathew:
    Maybe I'm missing something, but it looks like the typical way people have to code around the limitations of statically typed languages such as Java in order to implement polymorphism.
    Yep. You're missing something. Have you ever even looked at Java? This isn't a workaround to any limitation - it's basically completely unnecessary code.
  • blueRaja (unregistered)

    Hello sir, I'm an overloaded method - I see we haven't met before.

  • Andrew (unregistered) in reply to diaphanein
    diaphanein:
    durnurd:
    Seriously, shouldn't people just assume that people who are blatantly explaining the WTF and what they should have done are generally doing it in a sarcastic manner?

    Just stop trying to correct people, people.

    But someone on the internet is WRONG! And they'll stay that way if I don't correct them. (Thx, xkcd)

    We are thousand code monkeys with a thousand keyboards. Eventually we'll write a correct program!

  • (cs)

    Loading bullets into a gun and then throwing the entire weapon at the target eh?

  • kokomo (unregistered)

    Most people don't know how to use polymorphism. I bet half of the readers didn't understand this. ;-)

  • (cs) in reply to Anonymous
    Anonymous:
    "schedule" is one of those words that cease to make any rational sense after staring at it too long.

    For me it's "else." That can get to be a problem when you're coding.

  • (cs) in reply to alegr
    alegr:
    I've seen code like that:

    switch(pObj->GetType()) { case Type1: delete (ObjectType1*) pObj; break; case Type2: delete (ObjectType2*) pObj; break; case Type3: delete (ObjectType3*) pObj; break; case Type4: delete (ObjectType4*) pObj; break; }

    Apparently, a concept of virtual destructor has escaped the designers. This code might be running in your laptop, controlling your soft modem.

    Seemingly, all concepts of virtual destructor have escaped the "designers" (although, in this case, I believe you mean "ignorant and dangerous morons").

    Slice me silly, but this just doesn't work.

    Anyway, who are you to call my modem soft? My modem will take your modem on any time. Electron guns behind the bike sheds at midnight, mate.

    This is by far the best comment so far. At least 75% of the others are simply too sad to contemplate.

  • Franz Kafka (unregistered) in reply to alegr
    alegr:
    I've seen code like that:

    switch(pObj->GetType()) { case Type1: delete (ObjectType1*) pObj; break; case Type2: delete (ObjectType2*) pObj; break; case Type3: delete (ObjectType3*) pObj; break; case Type4: delete (ObjectType4*) pObj; break; }

    Apparently, a concept of virtual destructor has escaped the designers. This code might be running in your laptop, controlling your soft modem.

    Heh, of course, the concept of virt destructors has escaped lots of developers too. At least this works (if you maintain the switch statement).

  • Bean (unregistered)

    For those who don't understand the WTF. Using interfaces means they all share the same base set of methods, just the implementation is different. It is similar to having abstract classes. So he/she doesn't need to check they type of schedule and in fact just call the method defined in the interface. IE one line of code after you have the object.

  • John (unregistered)

    Got a laugh out of this one. The problem is that he's casting the object to the more specific class in order to call an interface method on it.

    The whole point of the interface is that you can call the same method on any object that implements it, regardless of whether your reference is specific or not.

  • (cs) in reply to Bmfzzld
    Bmfzzld:
    DeltaGeek:
    ParkinT:
    Now that really makes me say WTF! That's like inventing the wheel and trying to roll it SIDEWAYS!!
    Oh, you saw that Superbowl commercial too?

    Wheel suck.

    (or in this case) Interface suck.

    Bottle opener suck!

  • Barf 4Eva (unregistered)

    heheh, funny. Well, not too big a WTF. Mis-use of interfaces, could of saved himself quite a bit of code, potentially... had he just appropriately outlined the method in the interface and implemented it correctly in the classes inheriting the interface. But if it works, oh well, move on and learn from it...

    The thing that really gets me, is about 2/3 the time I decide I need an interface while modeling out what needs to be developed, I don't really need it (at least in the context that I was trying to) and there was either a simpler way to do it (KISS) or I should of read up on the appropriate design pattern and used an interface in a more appropriate manner.

  • Bmfzzld (unregistered) in reply to Digitalbath
    Digitalbath:
    Bmfzzld:
    DeltaGeek:
    ParkinT:
    Now that really makes me say WTF! That's like inventing the wheel and trying to roll it SIDEWAYS!!
    Oh, you saw that Superbowl commercial too?

    Wheel suck.

    (or in this case) Interface suck.

    Bottle opener suck!

    See how much joy there is in belittling the fallacies of simpler people that we don't understand? Shame on those who would hinder our happiness.

  • (cs)

    I'm still deciding what The Real WTF is, the 20 people who skipped all of the comments and had to outline exactly why this is so stupid, or the 20 people who skipped all of the comments and posted to say they didn't understand the WTF.

  • BBBlah (unregistered)

    Hmm

    ISchedule schedule = ScheduleFactory
   .GetSchedule(Convert.ToInt32(SchedulesList.SelectedValue));
IScheduledTask nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

    Wouldn't that be equivalent?

  • I walked the dinosaur (unregistered) in reply to BBBlah
    BBBlah:
    Hmm 
    ISchedule schedule = ScheduleFactory
   .GetSchedule(Convert.ToInt32(SchedulesList.SelectedValue));
IScheduledTask nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

    Wouldn't that be equivalent?

    • See Above.
  • facilisi (unregistered)

    Looks like someone needs a beat down with a sack of Delegate functions:D

  • Long (unregistered) in reply to It's a Feature
    It's a Feature:
    Jens:
    Don't know api, but i guess he could have just:

    nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

    or am I missing something.

    He was very close to a major breakthrough. Yes, this would have worked--but he first needed to add GetNextScheduledTask to the interface, which would have prevented the code from compiling unless the classes all implemented the method, which would have then made the above code valid.

    Not to mention, if a bunch of WackySchedule interfaces are not to be trusted, the code would only get the schedule from the truested ones. This is where "refactoring" the code would suddenly cause strange things to happen.

  • gisTimmy (unregistered) in reply to alegr

    I've written code like that...

    ...but I never checked it in.

  • Exick (unregistered)

    The WTF really is only peripherally related to Class Factories, virtual functions, polymorphism, and interfaces. Sure, familiarity with those concepts can guide you toward the correct solution, but fundamentally this wtf boils down to the programmer going out of his way to force the object into a certain state immediately after verifying that said object is already in the state he wishes it to be in. Even without any knowledge of OO concepts, someone can look at that and tell that the code is flawed by unnecessary steps.

  • (cs) in reply to It's a Feature
    It's a Feature:
    Jens:
    Don't know api, but i guess he could have just:

    nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

    or am I missing something.

    He was very close to a major breakthrough. Yes, this would have worked--but he first needed to add GetNextScheduledTask to the interface, which would have prevented the code from compiling unless the classes all implemented the method, which would have then made the above code valid.

    Which they did. You can't know this from reading it, but the snippet in the article lists all variations on the Schedule class.

    In fact, after finding this code, I just added the relevant function to the interface and replaced the block with the obvious.

  • Travis (unregistered) in reply to ParkinT

    ParkinT,

    How true. That explanation is perfect!

  • (cs) in reply to gisTimmy
    gisTimmy:
    I've written code like that...

    ...but I never checked it in.

    You never used version control ? ;-)

  • captain obvious (unregistered) in reply to Coderguy
    Coderguy:
    Optimizer:
    Yeah, using "else if" would make that code run way faster, especially if you optimize to put the common cases upfront. :)

    You know, the funny thing about this comment is that you, too, absolutly missed the real point about what is wrong with the code ;)

    Just a hint: The concept is called virtual function...

    Not only did you fail to see it was sarcasm, but you idiotically call it the "virtual function" concept. It is "polymorphism"

  • (cs) in reply to snoofle
    snoofle:
    [...] (eg: you are correct)
    Okay, I'm totally going to look like a grammar snob, but this is something I didn't know for a long time, even though I considered myself to be adept at English, so please take this as an informative tip, not as an "I'm offended that you made a grammar mistake."

    e.g. means "for example," usually preceding a list of possible items. i.e. means "that is," used to further clarify a statement.

    And you can now proceed to tell me my post is irrelevant and rude =)

    EDIT: Reading through the rest of the posts, I had to race for the edit button. taylonr corrected it first, and felt just as bad about making the correction. At least we can share the blasting...

  • speedothebrief (unregistered) in reply to JP London
    JP London:
    I too often see code like this, why bother define and use interfaces if you going to stick in a static if/else or switch block anyway.

    Get rid of the id and a single line solves your issues:

    IScheduledTask nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

    I'm currently reviewing code and have come across the following so many times:

    boolean rtn = false; if ( <expression> ) { rtn = true; } return rtn;

    Review comment:

    how about using the following boolean rtn = <expression>;

    Actually, there are some reasons for doing this kind of thing (I'm not sure I completely comprehend the risk of mockery I am undertaking by saying this... but what the hell...). I assume that when you say you see a lot of...

    boolean rtn = false; if ( <expression> ) { rtn = true; } return rtn;

    you are probably actually saying that there is something more like this going on...

    boolean rtn = false; <lots of other code> if ( <expression> ) { rtn = true; } else { <lots of more code> rtn = } <maybe even some more code> return rtn;

    I think that this is very well structured, even though you could save many lines of code by returning from within the if blocks, because code that always returns at the end of the method is generally easier to read.

    I almost added some extra stuff here to comment on how I find it interesting that so many people feel so compelled to correct the poor souls whose code ends up in articles here, but then I realized that I'm now guilty of a similar crime. After a little more thought... bah... tear 'em to shreds!
  • Anonymous (unregistered)

    Hmmm, just yesterday I fixed exactly the same case in our productive code :)

    The code just grew historically: First there was only one if with special handling. Then an else-if joined with a little different handling. This else-if was then copied multiple times, but there was still a special handling for the first one. Finally the behaviour of the first if was unified with the other if's. And BAM - we had this WTF ...but in our case with > 30 if-operations.

    BTW: The class was a comparator and used very often :)

  • grawity (unregistered)

    you think this is bad? take a look at this: http://www.ohnorobot.com/js/32.js

    excerpt: var u=new Array(); u[0]=".php=1"; u[1]=".php=100"; u[2]=".php=140"; u[3]=".php=101"; u[4]=".php=481"; u[5]=".php=161"; u[6]=".php=10"; u[7]=".php=12"; u[8]=".php=151"; u[9]=".php=16"; u[10]=".php=164"; u[11]=".php=51"; u[12]=".php=157"; u[13]=".php=158"; u[14]=".php=163"; u[15]=".php=114"; u[16]=".php=116"; u[17]=".php=117"; u[18]=".php=118"; u[19]=".php=119"; u[20]=".php=120"; u[21]=".php=509"; u[22]=".php=121"; u[23]=".php=122"; u[24]=".php=514"; u[25]=".php=123"; u[26]=".php=124"; u[27]=".php=125"; u[28]=".php=126"; u[29]=".php=127"; u[30]=".php=128"; u[31]=".php=129"; u[32]=".php=130"; u[33]=".php=131"; u[34]=".php=132"; u[35]=".php=492"; u[36]=".php=493"; u[37]=".php=513"; u[38]=".php=490"; u[39]=".php=510"; // snip

  • Tei (unregistered) in reply to grawity
    grawity:
    you think this is bad? take a look at this: http://www.ohnorobot.com/js/32.js

    excerpt: var u=new Array(); u[0]=".php=1"; ... u[35]=".php=492"; u[36]=".php=493"; u[37]=".php=513"; u[38]=".php=490"; u[39]=".php=510"; // snip

    This could be dinamically generated.

  • Polymorph (unregistered)

    I dread to contemplate how that code might improve just five minutes AFTER the major breakthrough. Oh, so you can just call the GetNextScheduledTask() method directly on something of the ISchedule type?

    if(schedule is DailySchedule)
{
   DailySchedule daily = (DailySchedule)schedule;
   ((ISchedule)daily).GetNextScheduledTask(startTime,true);
}
if(schedule is WeeklySchedule)
{
   WeeklySchedule weekly = (WeeklySchedule)schedule;
   ((ISchedule)weekly).GetNextScheduledTask(startTime,true);
}
    There! Learned about polymorphism! What a major breakthrough! ;-)
  • (cs)

    Makes sense to me... IF he did the following: if() {

    } else if () {

    } ...

    And a big comment on top: //We might have to do special handling for specific schedule types...

    Instead "its like inventing the wheel and rolling it sideways" is the correct response to that.

  • (cs) in reply to icelava
    icelava:
    Loading bullets into a gun and then throwing the entire weapon at the target eh?

    This is the best comment here.

    You win internet, sir.

  • Tom (unregistered) in reply to David

    Two Words. Code. Review.

  • umm... (unregistered) in reply to sf
    sf:
    Another WTF is the stupid Microsoft practice of prefixing interfaces with "I". I hate that crap.
    Apple must drive you iCrazy.
  • (cs) in reply to Outlaw Programmer
    Outlaw Programmer:
    I'm still deciding what The Real WTF is, the 20 people who skipped all of the comments and had to outline exactly why this is so stupid, or the 20 people who skipped all of the comments and posted to say they didn't understand the WTF.
    I've got a theory on this one, and it seems to apply to a whole buncha recent WTFs. It might even be generalisable across the Web.

    Admitting ignorance (or confusion) is no bad thing. These people have hope. We can fulfil their hope, brothers and sisters, as long as we tell them to read the thread from the top.

    Ninnies who believe that their audience really, really, really needs a badly-worded explanation of how objects/interfaces/virtual methods/overrides do the job, or (God help us) why this might be better expressed in a loop; well, they're just ninnies. It doesn't matter if they've read any of the preceding posts. They're just ninnies.

    To be honest, I prefer language wars to that sort of stupidity. I vote for the "don't understands." And I fear for the future.

  • Booger (unregistered) in reply to speedothebrief
    speedothebrief:
    JP London:
    I too often see code like this, why bother define and use interfaces if you going to stick in a static if/else or switch block anyway.

    Get rid of the id and a single line solves your issues:

    IScheduledTask nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

    I'm currently reviewing code and have come across the following so many times:

    boolean rtn = false; if ( <expression> ) { rtn = true; } return rtn;

    Review comment:

    how about using the following boolean rtn = <expression>;

    Actually, there are some reasons for doing this kind of thing (I'm not sure I completely comprehend the risk of mockery I am undertaking by saying this... but what the hell...). I assume that when you say you see a lot of...

    boolean rtn = false; if ( <expression> ) { rtn = true; } return rtn;

    you are probably actually saying that there is something more like this going on...

    boolean rtn = false; <lots of other code> if ( <expression> ) { rtn = true; } else { <lots of more code> rtn = } <maybe even some more code> return rtn;

    I think that this is very well structured, even though you could save many lines of code by returning from within the if blocks, because code that always returns at the end of the method is generally easier to read.

    I almost added some extra stuff here to comment on how I find it interesting that so many people feel so compelled to correct the poor souls whose code ends up in articles here, but then I realized that I'm now guilty of a similar crime. After a little more thought... bah... tear 'em to shreds!

    An even shorter version would dispense with the 'rtn' stack variable entirely. Assuming it is not read anywhere: function x() { return <expression> }

    However, even if it isn't read, then -- assuming it isn't optimized away -- a reason for using a 'rtn' variable might be that the programmer wants to be able to step over the assignment in a debugger and check the value before returning from the function.

    Finally, a reason for NOT doing it as suggested, i.e. initializing the stack variable by setting it to the expression, is that the expression may be complex, possibly throw an exception, and one may wish to catch the exception, returning the default value and also perhaps log the return value:

    function x() { boolean rtn = true; try { rtn = <expression>; } catch (Exception e) { log.error(e); } finally { log.debug("rtn = " + rtn); } return rtn; }
  • (cs) in reply to taylonr
    taylonr:
    snoofle:
    Jens:
    Don't know api, but i guess he could have just:

    nextScheduledTask = schedule.GetNextScheduledTask(startRunTime, true);

    or am I missing something.

    He could simply have omitted the typecast and done it precisely once instead of an via if-else chain (eg: you are correct)

    All right, I might get blasted for this, but I think you want "(i.e.: you are correct)" instead of the eg. It's a minor annoyance I have ;) EG means "For example" and IE means "In other words"

    /Knowing is half the battle

    Actually, EG is a magazine and IE is a web browser. Perhaps your looking for "e.g." and "i.e."?

  • spacebat777 (unregistered) in reply to Optimizer

    Optimizer... <smack>

  • penguin (unregistered) in reply to Optimizer

    Optimizer.. you're an idiot.

Leave a comment on “Barely Missing the Concept”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article