Just plain ol' code WTFs



  • Sure, this works, but wtfwtt?

    Were they practicing all the different ways you can refer to a property of a JavaScript object?

    <font face="courier new,courier" size="3">function isChecked(field){
    return eval("document.forms['MyForm']."+field+".checked");
    }</font>

    This one I just can't understand:

    <font face="courier new,courier" size="3">if (fld.name && typeof(fld.name) == 'undefined') {
    /* snip */
    }</font>

    Also, I've been seeing this pattern lots of times:

    <font face="courier new,courier" size="3">if( P || (!P && Q) ){
    /* snip */
    }</font>

    Anyone care to try advancing aplausible explanation as to why this pattern may be used? The way I see it, it slows down expression evaluation -- with or without of evaluation shortcutting -- and decreases legibility, specially when P is textually big.

    EDIT: aplausible, n: an explanation so likely to be true, it is worthy of applause



  • @Zecc said:

    Were they practicing all the different ways you can refer to a property of a JavaScript object?

    <font size="3" face="courier new,courier">function isChecked(field){
    return eval("document.forms['MyForm']."+field+".checked");
    }</font>

    I've been telling them for years, Javascript needs variable variables  just to prevent things like this!

    @Zecc said:

    Anyone care to try advancing aplausible explanation as to why this pattern may be used? The way I see it, it slows down expression evaluation -- with or without of evaluation shortcutting -- and decreases legibility, specially when P is textually big.

    I don't know exactly why and how this is used, but isn't that the easiest way if you want to do something, well, when either condition P or not condition P but condition Q?




  • @dtech said:

    @Zecc said:

    Anyone care to try advancing aplausible explanation as to why this pattern may be used? The way I see it, it slows down expression evaluation -- with or without of evaluation shortcutting -- and decreases legibility, specially when P is textually big.

    I don't know exactly why and how this is used, but isn't that the easiest way if you want to do something, well, when either condition P or not condition P but condition Q?

     

    No, "P || (!P && Q)" is exactly equivelent to "P || Q".



  • @mallard said:

    @dtech said:

    @Zecc said:

    Anyone care to try advancing aplausible explanation as to why this pattern may be used?
    The way I see it, it slows down expression evaluation -- with or without of evaluation shortcutting -- and decreases legibility, specially when P is textually big.

    I don't know exactly why and how this is used, but isn't that the easiest way if you want to do something, well, when either condition P or not condition P but condition Q?

     

    No, "P || (!P && Q)" is exactly equivelent to "P || Q".

    If your language has side effects but not short-circuit evaluation, they're not equivalent, they're a mess.



  • @dtech said:

    I don't know exactly why and how this is used, but isn't that the easiest way if you want to do something, well, when either condition P or not condition P but condition Q?

    P || (!P && Q) is logically equivalent to P || Q, but you hit on the cause of the pattern: bad requirements gathering. Someone phrased the problem as, "Do it if the date is in the future, but also do it if the interest is compounded as long as the date is not in the future." That could be interpreted as the above, which is the same as "Do it if the date is in the future or the interest is compounded." Or it could be interpreted as (P && !Q) || (!P && Q): "Do it if the date is in the future _except if the interest is compounded_; do it if the interest is compounded as long as the date is not in the future."



  • @dtech said:

    I've been telling them for years, Javascript needs variable variables  just to prevent things like this!

    I really hope that was a joke :(



  • @Rank Amateur said:

    P || (!P && Q) is logically equivalent to P || Q, but you hit on the cause of the pattern: bad requirements gathering.

    Or changing requirements:

    Do this when P is true.

    if(P)

    Also when Q is true.

    if(P || Q)

    But not when both are true!

    if((P && !Q) || (!P && Q))

    No, wait, ALWAYS do it when P is true; we don't care what Q is in that case.

    if(P || (!P && Q))

    And there it is.

    (The developer never wrote "if(P ^ Q)" because he was a liberal arts major.)



  • @Howi said:

    @dtech said:

    I've been telling them for years, Javascript needs variable variables  just to prevent things like this!

    I really hope that was a joke :(

     

    Someone once had a bunch of those in a (failry simple) Perl test that I was in the code review for.  He thought they were pretty cool.  He didn't last too long here.



  • @Carnildo said:

    If your language has side effects but not short-circuit evaluation, they're not equivalent, they're a mess.
    Well said.

    Also, I forgot one:

    <font face="courier new,courier" size="3">if( !empty($somearr['someprop']) && isset($somearr['someprop']) ){
    // ...
    }</font>


  • @dtech said:

    @Zecc said:

    Were they practicing all the different ways you can refer to a property of a JavaScript object?

    <FONT size="3" face="courier new,courier">function isChecked(field){
    return eval("document.forms['MyForm']."+field+".checked");
    }</FONT>

    I've been telling them for years, Javascript needs variable variables  just to prevent things like this!

    Just in case you were being serious ... It has - sortof. In JavaScript, array and object notation are equivalent. In fact, they even used array notation once in the statement, but failed to recognise that they could use it a second time to avoid the overhead of eval:

    return document.forms['MyForm'][field].checked;



  • @Rank Amateur said:

    @dtech said:

    I don't know exactly why and how this is used, but isn't that the easiest way if you want to do something, well, when either condition P or not condition P but condition Q?

    P || (!P && Q) is logically equivalent to P || Q,

    Only if the || is xor, surely. (I'm not sure whether it is in JavaScript.)


  • P = true, Q = true, (P || (!P && Q)) = true, (P || Q) = true

    P = true, Q = false, (P || (!P && Q) = true, (P || Q) = true

    P = false, Q = true, (P || (!P && Q) = true, (P || Q) = true

    P = false, Q = false, (P || (!P && Q) = false, (P || Q) = false

     

    You see, if P is true, whatever is after || doesn't really matter.

    If P is false, (!P && Q) is logically equivalent to Q.



  • @NSCoder said:

    @Rank Amateur said:

    @dtech said:

    I don't know exactly why and how this is used, but isn't that the easiest way if you want to do something, well, when either condition P or not condition P but condition Q?

    P || (!P && Q) is logically equivalent to P || Q,

    Only if the || is xor, surely. (I'm not sure whether it is in JavaScript.)

    No. That would be (P&&!Q)||(!P&&Q)

    If P and Q are both true, then P||(!P&&Q) will evaluate to true (since the first part "P" will be true), so it is equivalent to P||Q



  • @Rank Amateur said:

    @dtech said:

    I don't know exactly why and how this is used, but isn't that the easiest way if you want to do something, well, when either condition P or not condition P but condition Q?

    P || (!P && Q) is logically equivalent to P || Q, but you hit on the cause of the pattern: bad requirements gathering. Someone phrased the problem as, "Do it if the date is in the future, but also do it if the interest is compounded as long as the date is not in the future." That could be interpreted as the above, which is the same as "Do it if the date is in the future or the interest is compounded." Or it could be interpreted as (P && !Q) || (!P && Q): "Do it if the date is in the future _except if the interest is compounded_; do it if the interest is compounded as long as the date is not in the future."

    Yep, they're all equivalent - unless (as someone else pointed out) P and/or Q are expressions with side-effects, in which case it's unsafe, or at least brittle, putting them in this expression anyway.

    I see this one quite often, and it annoys the $excrement out of me every time. I've even seen "P OR (Q AND NOT P) OR (R AND NOT P AND NOT Q)" in a SQL SELECT before now. Probably with extra, redundant brackets. This is just just "P or Q or R" in obfuscator's clothing. Plus, at least one of the three expressions was like some_table.some_column <= to_date(:date_in_a_string, 'DD/MM/YYYY') as well. Don't ask about dates-in-a-string, it's a Pro*C thing.

    I don't think it's down to bad requirements gathering, nor the history of the code. To me it looks like a bad optimisation, as if testing "P or Q" would over-do it because it sort of covers the case "P and Q" twice. Once you've tested P, you see, you don't need to test the case P and Q, so you test (Q and not P), and that's gotta be quicker, right?

    I've got a whole bag of Gaaaaah!! with these people's names on it.

     



  • @The General said:

    I see this one quite often, and it annoys the $excrement out of me every time. I've even seen "P OR (Q AND NOT P) OR (R AND NOT P AND NOT Q)" in a SQL SELECT before now. Probably with extra, redundant brackets. This is just just "P or Q or R" in obfuscator's clothing. Plus, at least one of the three expressions was like some_table.some_column <= to_date(:date_in_a_string, 'DD/MM/YYYY') as well. Don't ask about dates-in-a-string, it's a Pro*C thing.

     

    Jesus, what a bunch of whiners.  Yes, it's redundant, but it's plainly obvious what the code does, and the compiler is going to optimize out the extra evaluation anyway, so who cares?

    "Obfuscator's clothing?"  Are you trying to sound clever?



  • @Aaron said:

    Yes, it's redundant, but it's plainly obvious what the code does,
     

    You consider the logically challenged P OR (Q AND NOT P) OR (R AND NOT P AND NOT Q) to be nice clean code, when the alternative is P or Q or R?

    @Aaron said:

    who cares?

    The guy who maintains the code.

     



  • I think it's safe to say that the sane among us would use P or Q or R.



  • @Aaron said:

    the compiler is going to optimize out the extra evaluation anyway, so who cares?

    In JavaScript, the compiler is unlikely to optimise this expression. JavaScript is compiled on the fly, so it can't do quite so much optimisation in the compiler stage, since the compiler needs to be very fast, unlike languages where compiling is done slowly once, and executed multiple times. Especially since in most current browsers, the object referenced could have a getter (equivalent to an expression). It is simply a wasted expression with one more boolean operator, and one more [[get]] than it actually needs. Depending on where it is used, it could be just a harmless waste of a few CPU cycles, or it could be a bottleneck in a loop. On its own, it's unlikely to be a major problem, but it does show a lack of understanding of boolean logic in the coder, and a sign of more WTFs to come.



  • @TarquinWJ said:

    In JavaScript, the compiler is unlikely to optimise this expression.

    Just for interest's sake, I tested this in a few browsers; When P evaluates to true, the time taken is the same for (P||(!P&&Q)) is the same as (P||Q) (as expected due to the short circuit operator). When P evaluates to false, (P||(!P&&Q)) is about twice as slow as (P||Q) in IE, Opera, Firefox and Chrome. It's only about 15% slower in Safari, but it's still slower. So in all cases, it's best not to rely on the compiler to be smart.



  • #!/usr/bin/perl

    sub P {
        print "Function P called. Doing something drastic that shouldn't happen more than once.\n";
        return 0;
    }
    sub Q {
        print "Function Q called.\n";
        return 1;
    }

    if (P || (!P && Q)) {
        print "Woops!\n";
    }


  • Discourse touched me in a no-no place

    @ccjuju said:

    if (P || (!P && Q)) {
        print "Woops!\n";
    }
     

    So save the value of P in $p as the first comparison, and use $p in the second comparison.



  • @PJH said:

    @ccjuju said:

    if (P || (!P && Q)) {
        print "Woops!\n";
    }
     

    So save the value of P in $p as the first comparison, and use $p in the second comparison.

    Yes, I don't think anyone would be stupid enough* to put two function calls anywhere (expressions included), if it's supposed to be called only once.

    *Hahahahahahah


Log in to reply