• my name (unregistered)

    frist: as it is written, in the null check this.mode is assigned null secnod: mode always evaluates to invalid

  • Zatapatique (unregistered)

    Another WTF: nothing is done with the default value 4. Why don' t they set this.mode to 4 when the input is null?

  • Bogolese (unregistered)

    if (mode == null) { this.mode = mode; return ; }

    ^^^ THAT'S your WTF!!!!! ^^^

  • (nodebb)

    Did they not understand that and is a commutative operation?

    Two points here:

    1. If by "and" here, you meant &&, then I sure as hell hope they didn't understand that it's commutative, because && isn't commutative. Sure, the overall value doesn't depend on the order of the two values, but there's a difference between the behaviour of f(params) && g(params) and g(params) && f(params), so the order matters, and so the programming operation isn't commutative. (Yes, I agree that the fundamental logic operation is commutative, but && does shortcut evaluation, so the programming operation is not.)

    2. The correct thing to complain about is not "commutative" anyway, but rather "associative". All those extra parentheses indicate a failure to understand that the logic operation of && is associative, that is, that (a && b) && c and a && (b && c)and a && b && c are equivalent.

  • Tim Ward (unregistered)

    OK, so I normally say "if you can't remember the operator precedence rules for the language you're using this afternoon, FFS do not look them up, just put the brackets in. Because of the next poor sod who's going to read your code and who also doesn't remember the operator precedence rules."

    But ... surely ... "shortcut logical operators are left associative" applies across all languages, so doesn't need spelling out?

  • Chronomium (unregistered)

    Ah yes, the ancient times when Java didn't have enums, and the fight to be allowed to fix that in today's age.

  • Frodo B. (unregistered)

    they could have just used an Optional type, which is arguably the "right" option here.

    Optional is specifically intended as a RETURN type, not a PARAMETER type. Proof by authority: Brian Goetz.

    https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555

  • (nodebb)

    How about the WTF of not using a simple arithmetic check, since the valid values are a contiguous set of integers.

    if (mode < 0 || mode > 6)
  • (nodebb) in reply to Steve_The_Cynic

    Short-circuiting order of evaluation is irrelevant when the conditions have no side effects, like simple equality conditions. But you're right, this is an issue of associativity, not commutativity.

  • (nodebb) in reply to Barry Margolin

    Short-circuiting order of evaluation is irrelevant when the conditions have no side effects, like simple equality conditions.

    That did occur to me, about two milliseconds after I pressed "Submit". Oh well.

  • (nodebb)

    And there I just wondered why people would need the Delta nuget to handle etags over DB queries. Turns out some developers don't even understand basic boolean logic these days, not to mention that there are more conditional operators beyond equality checks.

  • Rob (unregistered) in reply to Barry Margolin

    Short-circuiting order of evaluation is irrelevant when the conditions have no side effects, like simple equality conditions.

    Order of evaluation still matters in short-circuiting without side effects. Consider the case where the null-check would be included in the if statement. It then needs to come first, otherwise the next check (code!= 1) will fail with an NPE.

  • Sara J (unregistered)

    I'd wager this wasn't written like this by hand, but rather the result of an IDE overzealously parenthesizing when doing some refactoring oppression and the dev just not bothering to fix it – got example iirc netbeans will sometimes give you something kind of like this when you have a bunch of chained ||s and hit "invert if"

  • Sara J (unregistered) in reply to Sara J

    for* example

  • Greg (unregistered) in reply to Tim Ward

    VB6 and VB.Net don't have short-circuit evaluation (unless you use AndAlso instead of And and OrElse instead of Or)

  • (nodebb) in reply to Rob
    Order of evaluation still matters in short-circuiting without side effects. Consider the case where the null-check would be included in the if statement. It then needs to come first, otherwise the next check (code!= 1) will fail with an NPE.

    Throwing an exception is a side effect (i.e. something other than returning a value).

  • (nodebb)

    How about the WTF of not using a simple arithmetic check, since the valid values are a contiguous set of integers.

    Well they are now, but that doesn't mean they always were or always will be.

    Furthermore, this mode thing doesn't look like it is meant to have the semantics of a number but numbers are merely used to label different modes. I'd feel uneasy about using properties of numbers on a type that really should be encoded as an enum.

Leave a comment on “What a More And”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article