- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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.
Admin
Yup. It's left-associative: https://docs.oracle.com/javase/specs/jls/se19/html/jls-15.html#jls-15.21
Admin
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.
Admin
"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!"
Admin
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
Admin
Those must be the salient lines of code Elon was talking about...
Admin
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 ;-)
Admin
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.
Admin
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.
Admin
I don't think so? Say the list has ten elements.
counterstarts at 0.(counter == customerList.size() - 1)is false. We continue. We incrementcounter, and continue the loop several more times. whencounterequals9,(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.Admin
The condition checks for
=== false, so the loop breaks on the first iteration in your example where (0 == 9) == falseAdmin
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.
Admin
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.
Admin
"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.
Admin
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.
Admin
Say more?
Admin
No we don't, we break because that
falseevaluation is compared for equality withfalse, which is true and the statement executed breaks out of the loop, .