• (cs)

     "You can buy it in any color, as long as it's black." -- Henry Ford

  • (cs)
  • goober foober (unregistered)

    Having deletes and any new states that may be introduced handled by the default case is a brilliant optimization saving untold slots in the jump table, and is also forward compatible.

  • (cs)

    I'm guessing (hoping?) these two code snippets were coded by forward-thinking coders for future enhancements or have had lines of code deleted from them and the switch and if/else statements not removed yet.

  • Name (unregistered)

    At least the first programmer added comments

    //Load Page Data



  • (cs)

    Bruhahahahahaha.  I love it when I see code like this.  It just makes my day.  [:D]

  • Kreiger (unregistered)

    No, it does not beg the question. It raises the question.

  • (cs)

    The second example simply covers both conditions: "Y" and Why Not?

  • C.Batt (unregistered)

    Meh.

    I'm betting that this is simply the results of rapid cut'n'paste code stubbing that the developer just hasn't returned to.

    Big freaking deal.  (Unless of course this is in production-ready code, then shame on the developer)

  • (cs)

    This code(found today by a coworker in production code) is (I think the) epitome of code that "does the same thing no matter what," and to really take the cake, that same thing is... NOTHING!

    Comments are as found.

    //--------------------------------------------------------------------------
    //
    //
    void pal_serial_1_task(UNSIGNED argc, VOID *argv)
    {
    //    byte tb[40];
    //    byte tbCnt=0;
        UNSIGNED            actual_flags;
        STATUS              status;
        NU_Sleep(5);
        TRACE("\n\rPort 1 running...");
           while(1){
            /* Retrieve events the event queue*/
            status = NU_Retrieve_Events(&Port_1_Events, SERIAL_NEW_CHAR|SERIAL_TIMEOUT|SERIAL_SYNC, NU_OR_CONSUME, &actual_flags, 30); //
            if ( status != NU_TIMEOUT) {
                if ( actual_flags & SERIAL_NEW_CHAR) {
    //              signBuildMsgId(128,MSG_GETCONFIG, 0, 0);
    //              TRACE("\n\rPort1 New Char");
    //              addTimeout(4,DEF_TM);
                }
    
            if ( actual_flags & SERIAL_TIMEOUT) {
    

    // processPortEvent(&uart_ports[4],PORT_EVENT_TIMEOUT); // TRACE("\n\rPort 1 timeout"); } if ( actual_flags & SERIAL_SYNC) { TRACE("\n\rSync 1"); // processPortEvent(&uart_ports[4],PORT_EVENT_SYNC); } } else { // signBuildMsgId(128,MSG_GETCONFIG, 0, 0); // Message = DO_WAIT; // status = NU_Send_To_Queue(&p5Queue, &Message, (UNSIGNED)1, // (UNSIGNED)NU_NO_SUSPEND);

        }
       }
    

    }

  • chad okere (unregistered)

    Um, could just be they plan to change the functions later on. Or planned on it and never did.

  • goober foober (unregistered) in reply to ernestpazera

    It does worse than nothing. It spins in a hard loop forever. But hey, at least it sleeps for what appears to be 5ms before doing so.  I assume this is to allow all the other processes to finish up before it goes hog-wild. hehehe

  • reniM (unregistered)

    i am not redundant

    i am not redundant

    i am not redundant

    i am not redundant

    i am not redundant

    ...

  • (cs)

    Ooo, those comments are great! I never would have been able to figure out what the LoadPageData() method does otherwise.

    I'm almost getting to the point where I think we should remove comments from the language.

  • Pat (unregistered)

    imho It looks more like a copy-and-pasting frenzy gone wrong, rather than an ignorance of not knowing how conditionals work..

     

  • Rick C (unregistered) in reply to C.Batt

    At the place I'm working, I've actually seen code like that second example, and yes, it's in production.

  • (cs) in reply to Pat

    What is remarkable about the first code example is that there is no "break" for the default case. So there is a little glimpse of hope ...

  • (cs)

    See boss.  My code isn't so bad at all, look at this: The daily wtf

  • jmo (unregistered)
    I saw one similar once..... using your example, it was the equivalent of the following
    switch (state)
    

    { case Enumerations.PageState.Edit: //Load Page Data LoadPageData(Enumerations.PageState.Edit); break; case Enumerations.PageState.Update: //Load Page Data LoadPageData(Enumerations.PageState.Update); break; case Enumerations.PageState.Add: //Load Page Data LoadPageData(Enumerations.PageState.Add); break; default: //Load Page Data LoadPageData(Enumerations.PageState.SomeDefault); }

     

  • (cs)

    This looks so familiar. A cow-orker (I 'inherited' his code in my last project) used to code like that. But one of his lines is still stuck in my head. I found it while I tried to do a little refactoring on his messy source:

    quantity += -1;

    I'm glad he's back in testing again.

  • ammoQ (unregistered) in reply to jmo

    Your example makes a bit more sense, because of the default branch.

  • (cs)

    I think its clear the first item in this post is a stub for future development. It just looks unfinished. Though I do love the redundant comment.

    The second example I could be less forgiving about. One explanation might be changing old, working code to do some new functionality, and not paying attention. You'd be suprised at how many strange bugs can pop up when you throw more developers at a project.

  • BitterLikeQuinine (unregistered)

    I once wrote a CASE tool to trap this sort of thing called TERSE: -

    "The Eliminator of Redundant Statements Eliminator".

    Perhaps I should dig it out and mail it to these people.

  • Rick Scott (unregistered) in reply to diGriz
    diGriz:
    This looks so familiar. A cow-orker (I 'inherited' his code in my last project) used to code like that. But one of his lines is still stuck in my head. I found it while I tried to do a little refactoring on his messy source:

    quantity += -1;

    I'm glad he's back in testing again.


    Laugh. Out. Loud. It is pretty hard to squeeze a WTF out of 2 assembly ops worth of code! Thanks for letting me start a Friday with a laugh <3
  • Robin Lavall&#233;e (unregistered) in reply to Rick Scott

    "Laugh. Out. Loud. It is pretty hard to squeeze a WTF out of 2 assembly ops worth of code! Thanks for letting me start a Friday with a laugh"

    Unless quantity is in a register, in which case only one op is needed:
    dec reg;

  • (cs) in reply to diGriz

    diGriz:
    This looks so familiar. A cow-orker (I 'inherited' his code in my last project) used to code like that. But one of his lines is still stuck in my head. I found it while I tried to do a little refactoring on his messy source:

    quantity += -1;

    I'm glad he's back in testing again.

    Hahahahahahaha,  must of never heard of "quantity -= 1;"  [:P]

  • (cs) in reply to cm5400

    you must be really stupid to write

    quantity += -1;

    instead of

    quantity -= 1;

    I mean, this one is so obvious.

  • (cs) in reply to bugmenot
    bugmenot:
    you must be really stupid to write

    quantity += -1;

    instead of

    quantity -= 1;

    I mean, this one is so obvious.


    you must be really stupid to write

    quantity -= 1;


    instead of


    quantity--;


    I mean, this one is so obvious.

    :-D

  • (cs) in reply to bugmenot
    bugmenot:
    you must be really stupid to write

    quantity += -1;

    instead of

    quantity -= 1;

    I mean, this one is so obvious.

    Almost as obvious as quantity--; but who cares?  Only the first one is funny.
  • SteveOw (unregistered) in reply to ernestpazera
    ernestpazera:

            if ( status != NU_TIMEOUT) {
                if ( actual_flags & SERIAL_NEW_CHAR) {
    //              signBuildMsgId(128,MSG_GETCONFIG, 0, 0);
    //              TRACE("\n\rPort1 New Char");
    //              addTimeout(4,DEF_TM);
                }

    I saw a variation on this theme in a production program where the programmer found that a bug fix caused a new bug.  The fix was to comment out the new code and reinstate the old code, with a comment to that effect. [:'(]

     Better the devil you know...

  • JJ (unregistered) in reply to sas

    And since we're being pedantic, we'd better write
    --quantity;
    since this doesn't introduce a temporary.

    Talking about obvious...

  • Purplet (unregistered) in reply to JJ

    Any compiler will optimize x++ to be equal to ++x when the expression value is not used and there is no overloaded operator.

    It all comes to style. Many prefer x+=1 instead of x++ (or ++x) because they find it more readable. Can't find a reason for X+=-1 though.

  • Purplet (unregistered) in reply to Purplet

    Of course I was thinking of --x, x-- and x-=1 :)

  • (cs) in reply to Purplet
    Anonymous:

    x-=1 :)


    I think you just invented a new emoticon.
  • Ion Todirel (unregistered)

    ...

    state = null;

    ...

    if(state != null) LoadPageData();

  • Scott McKellar (unregistered)

    Depending on the context, the first example may actually be reasonable.

    Given that it's branching on "state", it's probably part of a finite state machine -- or an event handler for a GUI, which amounts to the same thing.

    If I'm coding a finite state machine by hand, one way or another I need to branch on the combination of state and event, and there are a lot of combinations.  In order to keep the code manageable, I typically do the branching in a rigidly stereotyped way.  The results may include fragments that, considered in isolation, look just as silly as your example, but that doesn't bother me.  It's more important that the repetitive logical structure be immediately recognizable.  Also this stereotyped pattern makes it obvious where to put your changes if the state transition diagram changes.

    If I'm feeling ambitious, or lazy, I might even write a code generator in Perl or something to take over the tedium of writing voluminous stereotyped code.  Again the results may look silly in isolation, but I wouldn't care.  I'd rather rely on the compiler to optimize away the redundant tests than trust my own Perl script to treat the corresponding optimization as a special case.

Leave a comment on “1, 1, or 1, or if you really want, 1”

Log In or post as a guest

Replying to comment #32131:

« Return to Article