• -KK (unregistered)

    A question to the Java guys: Is the binary '==' operator guaranteed to be left-associative? Id est, is 'A == B == C' the same thing as (A == B) == C or could be interpreted as A == (B == C). To my eyes, A == B == C looks ambiguous and ought to be forbidden in the frist place.

  • ewie (unregistered) in reply to -KK

    Yup. It's left-associative: https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.21

  • (nodebb) in reply to -KK

    Is the binary '==' operator guaranteed to be left-associative?

    Yes. However, it's just as confusing to read at a glance as random mixings of ANDs and ORs in SQL - which also guarantees order, but the order it guarantees isn't intuitive to many.

  • (nodebb)

    "Today's lesson, class, is to write a comparison IF statement that compares two integers using a boolean expression. This will be very useful if you want to be a star on TheDailyWTF.com!"

  • Jaloopa (unregistered)

    Isn't this also going to guarantee that the loop only runs once? Unless there's only one entry in the list and then it will go out of bounds and presumably crash

  • maxInt (unregistered)

    Those must be the salient lines of code Elon was talking about...

  • (nodebb) in reply to -KK

    The correct answer is: Java is a proprietary non-standardized language owned by one of the greediest tech companies on this planet know for selling bugs as features. There is no guarantee for anything ;-)

  • (nodebb) in reply to MaxiTB

    Except perhaps that, as shown in this dependency graph https://en.wikipedia.org/wiki/Java_(programming_language)#/media/File:JavaUniverse.png , it's a big ball of fluff.

  • (nodebb) in reply to Jaloopa

    I'm glad I'm not the only one that read the code that way. Either something got switched by Remy when he anonymized it, or this code is not just ugly, but completely broken.

  • (author) in reply to Jaloopa

    I don't think so? Say the list has ten elements. counter starts at 0. (counter == customerList.size() - 1) is false. We continue. We increment counter, and continue the loop several more times. when counter equals 9, (counter == customerList.size() - 1) is now true. We break the loop. The trick- and this isn't something supplied in the submission- is where in the loop we do this break out relative to the increment and the access. I would just assume the were avoiding the crash.

  • (nodebb)

    The condition checks for === false, so the loop breaks on the first iteration in your example where (0 == 9) == false

  • (nodebb) in reply to -KK

    A == B == C looks ambiguous

    It isn't, but it is awful. In this case, things are helped slightly by the fact that booleans and integers are not interconvertible in Java at all. If you associated things the other way, you'd get a mandatory type error.

  • Flips (unregistered)

    I prefer to look at it, as just subtracting 2 booleans. Business as usual, I might add.

  • Jonathan (unregistered)

    (counter == customerList.size() - 1) is false. We continue...

    No, we break. As you point out, christ knows what it is we break out of, but we definitely break on the first pass through.

  • dpm (unregistered) in reply to Remy Porter

    No, Jaloopa is correct:

    if (0 == 10 - 1 == false) break; if (0 == 9 == false) break; if (false == false) break;

    the break is executed first time around.

  • Airdrik (unregistered) in reply to Remy Porter

    actually, the others are correct. At counter=0, (counter == customerList.size() - 1) is false as you said (unless the list has one element), but that is compared against false, so the whole if condition evaluates to true and it breaks out of the loop. The whole if condition only evaluates to false when counter = customerList.size() - 1.

    Granted it still depends on what else is going on. It could be that customerList is being populated by this loop and the check is along the lines of: if <other step(s)> did not add anything to the list (or added multiple items) such that customerList doesn't have a length matching the current loop count plus one.

  • xtal256 (unregistered)

    "The author didn't hang round long enough to have to deal with this mess."

    I've worked with many people like that and it annoys me because it's usually me left to clean up the mess.

  • (nodebb) in reply to dpm

    Just in case anyone doesn't understand why "unmaintainable" is not just as good as any other code as long as "it works" - especially if "it works" is determined by one or fewer poorly written test cases.

  • D (unregistered)

    The author didn't hang round long enough to have to deal with this mess? Or didn't live long enough to deal with the mess?

  • (nodebb) in reply to MaxiTB

    selling bugs as features

    Say more?

  • (nodebb) in reply to Remy Porter

    I don't think so? Say the list has ten elements. counter starts at 0. (counter == customerList.size() - 1) is false. We continue.

    No we don't, we break because that false evaluation is compared for equality with false, which is true and the statement executed breaks out of the loop, .

Leave a comment on “A False Comparison”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article