Comment On 1, 1, or 1, or if you really want, 1

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

OnceAndOnlyOnce

DontRepeatYourself

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.

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.

At least the first programmer added comments

//Load Page Data

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

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

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

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)

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);



        }

       }

}

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

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

i am not redundant

i am not redundant

i am not redundant

i am not redundant

i am not redundant

...

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.

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

 

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

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

See boss.  My code isn't so bad at all, look at this: HREF="" target="_blank">The daily
wtf

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);

}

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.

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

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.

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.

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

"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;

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]

you must be really stupid to write



quantity += -1;



instead of



quantity -= 1;



I mean, this one is so obvious.

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

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.

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

And since we're being pedantic, we'd better write

--quantity;

since this doesn't introduce a temporary.



Talking about obvious...

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.

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

Anonymous:

x-=1 :)

I think you just invented a new emoticon.

...

state = null;

...

if(state != null) LoadPageData();

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.

Out of runes of magic gold? Need it in urgent? Yes, I can understand you. As the most important currency, without rom gold, you ever can’t do anything. So you need to buy rom gold from those most professional and loyal game online shops with years’ experience and have a good reputation among players. Is there any difficult? No, when you need the rom gold, please feel free to contact us, we are promising to offer you the cheap runes of magic gold with fastest delivery. Moreover, we are online 24/7, you can contact us any time with any question about. So why are you still irresolute? Come here to grab your cheap runes of magic gold now.

Crazy about running warhammer gold? Yup, it is so crucial indeed for us in Warhammer Online. Without it, we can even do nothing, without money to buy items, weapons and so on. So enough warhammer gold is substantial.