• ExpatEgghead (unregistered)

    Can it be? Frist?

  • BlackBart (unregistered)

    LOL @ the boolean precision - they forgot to include "FILE_NOT_FOUND" in the precision allowances for the TRUE case.

  • Jay K. (unregistered)

    Only organized for clarity, not optimized comment.

    Clearly the second guy needs to reuse his equality functions like this:

    public static bool notEqual(Object obj1, Object obj2)
{
    if (obj1 == null && obj2 == null)
	return false;
    if (obj1 == "" && obj2 == null)
	return false;
    if (obj1 == null && obj2 == "")
	return false;
    if (obj1 == null || obj2 == null)
	return true;
    if (isEqual(obj2))
	return false;
    return true;
}

public static bool isEqual(Object obj1, Object obj2)
{
    if (obj1 == null || obj2 == null)
	return false;
    if (obj1 == "" && obj2 == null)
	return false;
    if (obj1 == null && obj2 == "")
	return false;
    if (isNotEqual(obj2))
	return false;
    return true;
}
public static bool isNotEqual(Object obj1, Object obj2)
{
    if (obj1 == null && obj2 == null)
	return false;
    if (obj1 == null && obj2 == "")
	return false;
    if (obj1 == "" && obj2 == null)
	return false;
    if (obj1 == null)
    {
	if (obj2 != null) return true;
    }
    if (obj2 == null)
    {
	if (obj1 != null) return true;
    }
    if (notEqual(obj2))
	return true;
    return false;
}
  • Oded (unregistered)

    Love that "predified" precision.

  • IronMensan (unregistered)

    Quite a few of those look fine to me. == is all but useless with floating point numbers and a good epsilon depends on the context/expected range.

  • Larrik Jaerico (unregistered)

    The parts with the doubles (ie. abs(double1-double2) < TOLERANCE_CONSTANT) is not really a WTF. Sometimes you certainly can wind up with two values that are only 0.0000001 off or so, which are clearly equal for our purposes, but different to the computer. Either you can round first, or do it this way.

    The nulls checking logic is also only a possible WTF. Sometimes explicitly defining what happens when things are NULL is just a documentation requirement or somesuch. It IS mostly unnecessary, but it's not nearly worth posting here.

    (Of course I just replaced a 6000 line C program that made use of tiny variable names and loops filled with insane Switch/Case statements, so perhaps my bar for WTFs has gotten too high.)

  • C (unregistered) in reply to IronMensan
    IronMensan:
    Quite a few of those look fine to me. == is all but useless with floating point numbers and a good epsilon depends on the context/expected range.
    Depends on where you look...

    Most of the first ones are /valid/, but that's not necessarily 'fine' in my book. As for the second ones, they're simply atrocious. >:-P

  • Magnus (unregistered)

    No WTFs here, move along.

    As others have pointed out: for floats, you need an epsilon. Either you put it in a common function like here, or you put it in every single compare (which would not be fun to maintain).

    For the nulls, well, that's the alternative? obj1.equals(obj2) will give you a NullPointerException if obj1 is null. If your code really does have to deal with that condition, then this is the way to do it.

  • (cs)
    The Article:
    //Not optimized. Only layout like that for clarity.
    There's a classic example of "defensive commenting".

    Also, irony.

  • powercf (unregistered)

    The Date comparisons in #1 look fine to me also. I believe a Java Date includes hour, minute, second also. The comparison function is just comparing the year, month, day

  • (cs)

    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.

  • Rich the Engineer (unregistered)

    Obviously, all this object computing is too difficult for most of you "programmers". I recommend a return to assembly language, maybe you "programmers" can handle that, although I doubt it.

  • James Wilson (unregistered)

    The first example isn't a WTF at all, just poorly commented. The date comparison function is comparing two dates ignoring the time portion. In Java, Date.equals() returns false if you pass it another Date with the same calendar date but a different time. The function that checks for equality and handles the null cases is also completely fine and I have used a similar function when factoring redundant code. And as another commenter has pointed out, comparing doubles for equality REQUIRES the use of some epsilon. The only one I can't defend is the function checking two integers for equality, which looks like they just got a little too excited about this class.

    James

  • Caoilte (unregistered)

    For the nulls, well, that's the alternative?

    fail fast perhaps?

    I never found a case where assuming null==null was okay didn't obscure a deeper problem.

  • Todd Lewis (unregistered) in reply to Nagesh
    Nagesh:
    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.

    In other words, s/he needs to be NULLified. Then store his/her status in the data base as a... NULL?

    Oh, it's Nagesh. Never mind.

  • kadal (unregistered)

    Some equality are more equal than others

  • oh (unregistered)

    most of these are ok. Whoever submitted these just doesn't understand that sometimes you want to say that two things are equal even when they aren't exactly the same.

  • Eisentein (unregistered) in reply to kadal
    kadal:
    Some equality are more equal than others

    x = y // "y" is assigned to "x" x == y // "y" is logically equivalent to "x", can convert types if required x === y // "y" is identical to "x", no conversion of types allowed x ==== y // "y" is composed of the same electrons as "x" x ===== y // "y" ==== "x" and across all space/time continua

  • Lil'Troll (unregistered)

    The RWTF is Java for not implement equality right.

    Captch: enim - like enum, but with correct equality operators

  • Vlad Patryshev (unregistered)

    Nice code. Partially, it makes sense; in total, it is total nonsense.

    Thanks to the 1st amendment, any idiot can write code.

    The problem is, we have to deal with the results. Unlike speech which can be just ignored. And if the author is more than an idiot... oh God.

  • Danny (unregistered) in reply to Vlad Patryshev

    People stating there's no WTF here:

    public static bool isEqual(Object obj1, Object obj2) { ... if (obj1.Equals(obj2)) return false; return true; ... }

    TRWTF is your reading ability. Even if you don't find this kind of checking ridiculous, the code is broken anyway.

  • Toc the elder (unregistered) in reply to Larrik Jaerico
    Larrik Jaerico:
    The parts with the doubles (ie. abs(double1-double2) < TOLERANCE_CONSTANT) is not really a WTF. Sometimes you certainly can wind up with two values that are only 0.0000001 off or so, which are clearly equal for our purposes, but different to the computer. Either you can round first, or do it this way.

    The nulls checking logic is also only a possible WTF. Sometimes explicitly defining what happens when things are NULL is just a documentation requirement or somesuch. It IS mostly unnecessary, but it's not nearly worth posting here.

    (Of course I just replaced a 6000 line C program that made use of tiny variable names and loops filled with insane Switch/Case statements, so perhaps my bar for WTFs has gotten too high.)

    6000 lines with crazy switches eh? Directly coded finite state machines often end up looking like that, good times

  • BottomCod3r (unregistered)

    Um, why do the last 3 functions all look like they return the same thing.

    isEquals is notEquals is isNotEquals

  • (cs)

    A few of the posters seem to have overlooked a couple of points.

    equalsForMoney(double, double) implies that doubles are being used to store monetary values, which is an almost certain (in the measure-theoretic sense) indication of a design error.

    The comment on equals(int, int) is rather misleading.

  • Flaming Foobar (unregistered) in reply to Caoilte
    Caoilte:
    >I never found a case where assuming null==null was okay didn't obscure a deeper problem.

    What if you are synchronizing two whatevers and need to know if a value has changed, null being one of the possibilities?

  • Pete (unregistered) in reply to Danny

    which throws an exception when obj1 is null? Well done that man.

  • Anon (unregistered) in reply to Nagesh
    Nagesh:
    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.

    Amazingly Nagesh, the guy who invented Null sort of agrees with you.

  • (cs) in reply to oh
    oh:
    most of these are ok. Whoever submitted these just doesn't understand that sometimes you _want_ to say that two things are equal even when they aren't exactly the same.
    In several of those, the goal of the programmer isn't ridiculous. The implementation is uniformly )*&(@^#$, though.

    Some of those may have been forced on a maintenance coder by poor decisions elsewhere in the code. There's a point in working on a bug where you say to yourself, "Hmmm ... I can fix this by rewriting a few hundred lines each in several different subroutines, or I can throw together the world's ugliest kludge in a dozen lines or so ... (thinking) ... Hey, they don't pay by the line here, do they? Screw this, I'm hacking together something that works & then going to lunch on time for a change."

    Still a WTF, we just wouldn't necessarily be seeing the real WTF in this snippet.

    (Or is this where I say "TRWTF is Java"?)

  • (cs)

    Sounds like an idea for a new coder challenge... Prove in the language of your choice that 2 + 2 = 5 :)

    Bonus points for using extremely high level languages (like C#) or extremely low level langauges (like assembly)... it seems like it would be easiest to accomplish this in mid level languages like C++!

  • Anon (unregistered) in reply to Anon

    Trying that again... The guy who invented null kind of agrees with you.

    (And yet akismet thinks this one is spam?)

  • (cs) in reply to Larrik Jaerico
    Larrik Jaerico:
    The parts with the doubles (ie. abs(double1-double2) < TOLERANCE_CONSTANT) is not really a WTF. Sometimes you certainly can wind up with two values that are only 0.0000001 off or so, which are clearly equal for our purposes, but different to the computer. Either you can round first, or do it this way.

    Completely agree. But using floats for money is quite WTFish. Ihope nobody ever does anything important with his code.

    Magnus:
    No WTFs here, move along.

    ...

    For the nulls, well, that's the alternative? obj1.equals(obj2) will give you a NullPointerException if obj1 is null. If your code really does have to deal with that condition, then this is the way to do it.

    I'd settle fot a isEqual function that returns true if both arguments are equal. That does not seem to be the author's intention...

  • Cidolfas (unregistered)

    Have to agree that the Java code is largely perfectly reasonable. The only one that's really useless is the very last int comparison functions.

  • Toc the elder (unregistered) in reply to frits
    frits:
    The Article:
    //Not optimized. Only layout like that for clarity.
    There's a classic example of "defensive commenting".

    Also, irony.

    I write "defensive" comments quite often... although that one is pretty terrible. I would have just written it in an optimized way if I cared, then commented it for clarity... it's a pretty tiny and simple method, you'd have to work at it a bit to make it illegible (or write it in perl).

    I do defensive comments for the maintainer when the code I'm writing would make me think the original writer was a freakin' idiot on first glance, but needs to be done that way for some reason... or if I've maintained code that is very brittle, as a bit of a "here be dragons" style warning. I always tell myself I'll go back and untangle it later.. but of course there is never time and it is later forgotten.

  • (cs) in reply to Toc the elder
    Toc the elder:
    Larrik Jaerico:
    The parts with the doubles (ie. abs(double1-double2) < TOLERANCE_CONSTANT) is not really a WTF. Sometimes you certainly can wind up with two values that are only 0.0000001 off or so, which are clearly equal for our purposes, but different to the computer. Either you can round first, or do it this way.

    The nulls checking logic is also only a possible WTF. Sometimes explicitly defining what happens when things are NULL is just a documentation requirement or somesuch. It IS mostly unnecessary, but it's not nearly worth posting here.

    (Of course I just replaced a 6000 line C program that made use of tiny variable names and loops filled with insane Switch/Case statements, so perhaps my bar for WTFs has gotten too high.)

    6000 lines with crazy switches eh? Directly coded finite state machines often end up looking like that, good times

    Hah, last time I used something that compiled a state machine I was at my undergrad. God times, debuging thousands of lines of machine generated switches, with randomly generated labels, just to discover what the compiler understood from the input, so I could fix the input and get an assignment done.

    Good documentation is overrated.

  • QJ (unregistered)

    Nobody's complained yet about the fact that there's a utilities class of static methods that ultimately replace the standard java "obj.equals(Object o)" methods that all classes inherit?

    The fact that the methods are a little noobish (I've seen similar stuff written by otherwise perfectly reasonable developers at the start of the java part of their careers) is nothing near as bad as that.

  • Magnus (unregistered) in reply to pjt33

    Yes, storing monetary values in non-decimal floating point is always the wrong thing to do - unless some idiot is sending you monetary values in that form, in which case you may just have to deal with it.

  • Magnus (unregistered) in reply to Danny
    public static bool isEqual(Object obj1, Object obj2) { ... if (obj1.Equals(obj2)) return false; return true; ... }
    Yes, it would be two lines less to do
    return obj1.Equals(obj2);
    but doing it the current way keeps with the layout of the earlier tests. It's a matter of taste (and I think I'd write it the short way), but there's still no WTF here.
  • Jesper (unregistered)

    Those equals() methods look like what Eclipse would generate automatically (more or less).

    It's ugly, but not really a WTF. Unless you regards what Eclipse does a WTF.

  • (cs) in reply to Anon
    Anon:
    Trying that again... The guy who invented null kind of agrees with you.

    (And yet akismet thinks this one is spam?)

    "Please install flash player." Really informative.

  • (cs) in reply to Magnus
    Magnus:
    public static bool isEqual(Object obj1, Object obj2) { ... if (obj1.Equals(obj2)) return false; return true; ... }
    Yes, it would be two lines less to do
    return obj1.Equals(obj2);
    but doing it the current way keeps with the layout of the earlier tests. It's a matter of taste (and I think I'd write it the short way), but there's still no WTF here.
    Reading failure. Read the if() more carefully: if they are equal, return false, else return true, in a method called isEqual.
  • Magnus (unregistered) in reply to SCSimmons
    SCSimmons:
    (Or is this where I say "TRWTF is Java"?)
    TRWTH is that both the Java and the C# snippet look exactly the same. I mean, wasn't C# meant to improve on Java?
  • (cs)
    notEqual:
    if (obj1 == null || obj2 == null)
    return true;
    isNotEqual:
    if (obj1 == null)
{
    if (obj2 != null) return true;
}
if (obj2 == null)
{
    if (obj1 != null) return true;
}
    I'm wondering if he wrote notEqual first, then somebody told him how short-circuit evaluation works, so he wrote isNotEqual. Other than the above differences, they are more-or-less the same.
  • Naresh Kookaburra (unregistered) in reply to Magnus
    Magnus:
    SCSimmons:
    (Or is this where I say "TRWTF is Java"?)
    TRWTH is that both the Java and the C# snippet look exactly the same. I mean, wasn't C# meant to improve on Java?
    No.
  • Magnus (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Reading failure. Read the if() more carefully: if they are equal, return false, else return true, in a method called isEqual.
    Oh. W T F
  • (cs) in reply to Magnus
    Magnus:
    SCSimmons:
    (Or is this where I say "TRWTF is Java"?)
    TRWTH is that both the Java and the C# snippet look exactly the same. I mean, wasn't C# meant to improve on Java?
    Well, both Java and C# get their basic syntax from C/C++. A lot of code is interchangeable--in fact, I'm not positive glancing over it that the last snippet is C#. (It's not Java, but it could be C++, couldn't it? Or maybe not--I've been using VB.NET too long, so I've lost a lot of brain cells.)
  • (cs) in reply to Nagesh
    Nagesh:
    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.
    Nice try Nagesh-old-buddy, but the article doesn't appear to have anything to do with RDBMS.

    Keep on trollin!

  • BentFranklin (unregistered) in reply to Eisentein
    Eisentein:
    kadal:
    Some equality are more equal than others

    x = y // "y" is assigned to "x" x == y // "y" is logically equivalent to "x", can convert types if required x === y // "y" is identical to "x", no conversion of types allowed x ==== y // "y" is composed of the same electrons as "x" x ===== y // "y" ==== "x" and across all space/time continua

    (equal x y) x and y evaluate to the same result (eq? x y) x and y are the same object

  • (cs) in reply to QJ
    QJ:
    Nobody's complained yet about the fact that there's a utilities class of static methods that ultimately replace the standard java "obj.equals(Object o)" methods that all classes inherit?
    Well, no, you get a NullPointerException if obj is null. This handles that case (which I agree is suspicious), but in a very inefficient way. This is a lot shorter: 
    public static boolean isEquals( Object o1, Object o2 )
{
    return o1 == null ? o2 == null : o1.equals( o2 );
}
  • Vacaloca (unregistered) in reply to SCSimmons
    SCSimmons:
    Magnus:
    SCSimmons:
    (Or is this where I say "TRWTF is Java"?)
    TRWTH is that both the Java and the C# snippet look exactly the same. I mean, wasn't C# meant to improve on Java?
    Well, both Java and C# get their basic syntax from C/C++. A lot of code is interchangeable--in fact, I'm not positive glancing over it that the last snippet is C#. (It's not Java, but it could be C++, couldn't it? Or maybe not--I've been using VB.NET too long, so I've lost a lot of brain cells.)

    Sounds like you should go back to VB6 is this wasn't a dead giveaway..

    import java.util.Calendar; import java.util.Date; import java.util.GregorianCalendar;

    import org.apache.log4j.Logger;

  • (cs) in reply to Anon
    Anon:
    Nagesh:
    In my point of view, NULLS are completely useless and stupid. Whoever came with NuLL concept need to be drawn, quartered and then left to rot on the pikes of the RDBMS compound.

    Amazingly Nagesh, the guy who invented Null sort of agrees with you.

    Have you not found URL tag yet? I corrected the above link for you.

Leave a comment on “The Qualities of Equality”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article