• Black Bart (unregistered)

    Steve is a Java refugee, who had his hand slapped for using == for string comparison instead of equals and found that it didn't work. After his migration to c#, he messed up his frist assignment.

  • Anonymous (unregistered) 
    String wtf = "WTF";
if ((article.text().hashCode()) == wtf.hashCode()) wtfCount++;
  • (cs)
  • Yuval (unregistered) in reply to Black Bart
    Black Bart:
    Steve is a Java refugee, who had his hand slapped for using == for string comparison instead of equals and found that it didn't work. After his migration to c#, he messed up his frist assignment.

    Bull. C#'s string is lowercased.

  • (cs)

    PostComment("X" + Character.toString(961 + (int)'E') + "S")

  • yourName (unregistered) in reply to Yuval
    Yuval:
    Black Bart:
    Steve is a Java refugee, who had his hand slapped for using == for string comparison instead of equals and found that it didn't work.   After his migration to c#, he messed up his frist assignment.
      Bull. C#'s string is lowercased.

      "In C#, the string keyword is an alias for String. Therefore,String and string are equivalent, and you can use whichever naming convention you prefer."

      http://msdn.microsoft.com/en-us/library/ms228362.aspx

  • (cs) in reply to Black Bart
    A man with one watch always knows what time it is. A man with two watches never does.
    This is also applicable to storing multiple copies of the same data.
  • (cs)

    If he's a septic doesn't that just mean he's from the USA? Yank => septic tank => seppo...

  • moz (unregistered) in reply to OzPeter
    OzPeter:
    A man with one watch always knows what time it is. A man with two watches never does.
    And a man with two watches, one of which has stopped, knows what time it is twice a day.

    Or maybe this is all rubbish, and people are smarter than hashing algorithms.

  • DanielD (unregistered)

    TRWTF is that while being overly sceptical about the String comparison, he obviously sees null checks as a complete waste of time...

  • RWTF (unregistered)

    The real WTF is the long and strange introduction for a short snippet of code.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    String filenotfound = "FILE_NOT_FOUND"; if ((result.hashCode()) == filenotfound.hashCode()) throw "File not found!";

  • fa2k (unregistered) in reply to OzPeter
    OzPeter:
    A man with one watch always knows what time it is. A man with two watches never does.
    This is also applicable to storing multiple copies of the same data.
    A man with one watch knows what time it is, but doesn't know if it's correct.

    A man with two watches either knows what time it is and is reasonably sure that it's correct, or knows that either of the clocks are incorrect

  • Pock Suppet (unregistered) in reply to fa2k
    fa2k:
    OzPeter:
    A man with one watch always knows what time it is. A man with two watches never does.
    This is also applicable to storing multiple copies of the same data.
    A man with one watch knows what time it is, but doesn't know if it's correct.

    A man with two watches either knows what time it is and is reasonably sure that it's correct, or knows that either of the clocks are incorrect

    The only solution is to get more data points. Wear a hundred watches, then throw out any data that doesn't fit your preconceived conception of what time it is.

  • Doodpants (unregistered) in reply to Black Bart
    Black Bart:
    Steve is a Java refugee, who had his hand slapped for using == for string comparison instead of equals and found that it didn't work. After his migration to c#, he messed up his frist assignment.
    Except that the code shown *is* Java, as evidenced by the method "hashCode" instead of "GetHashCode".
  • (cs) in reply to fa2k
    fa2k:
    OzPeter:
    A man with one watch always knows what time it is. A man with two watches never does.
    This is also applicable to storing multiple copies of the same data.
    A man with one watch knows what time it is, but doesn't know if it's correct.

    A man with two watches either knows what time it is and is reasonably sure that it's correct, or knows that either of the clocks are incorrect

    Which is why you keep one clock on a ship, or three clocks.

  • Limeys suck (unregistered) in reply to Zemm
    Zemm:
    If he's a septic doesn't that just mean he's from the USA? Yank => septic tank => seppo...

    Ha ha, and calling a phone a "dog" comes from "dog and bone" to "telephone," if it sounds like something your grandparents would come up with, that's because it is.

  • (cs)

    So, TRWTF is the author for not knowing that using == to compare Java Strings for equality flat-out doesn't work.

  • (cs)

    That is java code.

  • goat (unregistered) in reply to The_Assimilator

    It doesn't flat out not work. If both values have been interned, it works - alternately if values have not been interned but happen to actually be the same reference, it works. If it flat out didn't work, that would actually be a kindness. However, one might do best to go along thinking it flat out doesn't work.

  • (cs) in reply to The_Assimilator
    The_Assimilator:
    So, TRWTF is the author for not knowing that using == to compare Java Strings for equality flat-out doesn't work.
    No, TRWTF is that neither the author of the code nor the author of the grist for the article know about the equals() method. It's only one of the most introductory things taught to anyone who uses Java. (Also, it doesn't handle all the other kinds of string that might mean that things ought to be switched on, but we'll ignore that for now…)
  • anonymous (unregistered) in reply to fa2k
    fa2k:
    OzPeter:
    A man with one watch always knows what time it is. A man with two watches never does.
    This is also applicable to storing multiple copies of the same data.
    A man with one watch knows what time it is, but doesn't know if it's correct.

    A man with two watches either knows what time it is and is reasonably sure that it's correct, or knows that either of the clocks are incorrect

    It doesn't matter how many clocks a man has; what matters is what he sets them by. If he sets them by an authoritative source, he only needs one clock; if he sets them by other non-authoritative clocks, it doesn't matter how many clocks he has because they'll all be just as wrong as the time source he used to set them by.

  • (cs) in reply to dkf
    dkf:
    The_Assimilator:
    So, TRWTF is the author for not knowing that using == to compare Java Strings for equality flat-out doesn't work.
    No, TRWTF is that neither the author of the code nor the author of the grist for the article know about the equals() method. It's only one of the most introductory things taught to anyone who uses Java. (Also, it doesn't handle all the other kinds of string that might mean that things ought to be switched on, but we'll ignore that for now…)

    equals in 1.6 does not handle Unicode. try to equal two character in Devnagari and you will know what I mean.

  • Valued Service (unregistered) in reply to goat
    goat:
    It doesn't flat out not work. If both values have been interned, it works - alternately if values have not been interned but happen to actually be the same reference, it works. If it flat out didn't work, that would actually be a kindness. However, one might do best to go along thinking it flat out doesn't work.

    I know what.

    We should come up with two methods.

    One called Equals, and the other ReferenceEquals.

    That way we know exactly what we're checking each time.

  • Kevin (unregistered) in reply to yourName

    [quote user="yourName]"In C#, the string keyword is an alias for String. Therefore,String and string are equivalent, and you can use whichever naming convention you prefer." [/quote] As long as you prefer the lowercased version.

  • (cs) in reply to Black Bart
    Black Bart:
    Steve is a Java refugee, who had his hand slapped for using == for string comparison instead of equals and found that it didn't work. After his migration to c#, he messed up his frist assignment.

    I see nothing in this code that makes me think this is a language other than Java. After all, .hashCode() is a Java construct. The C# equivalent is .GetHashCode()

  • (cs) in reply to Nagesh
    Nagesh:
    dkf:
    The_Assimilator:
    So, TRWTF is the author for not knowing that using == to compare Java Strings for equality flat-out doesn't work.
    No, TRWTF is that neither the author of the code nor the author of the grist for the article know about the equals() method. It's only one of the most introductory things taught to anyone who uses Java. (Also, it doesn't handle all the other kinds of string that might mean that things ought to be switched on, but we'll ignore that for now…)

    equals in 1.6 does not handle Unicode. try to equal two character in Devnagari and you will know what I mean.

    That sounds like a bug since Java Strings are stored as UTF-16 internally (likely Big Endian across all platforms for consistency, but I'd have to consult the standard). They were originally USC-2 in early Java versions, but switched to UTF-16 when it became apparent that 16-bit characters still weren't large enough to store all the characters for all the world's languages.

  • Bobby (unregistered)

    setDelay("YES"); ...do stuff... setDelay("NO"); // <---- FAIL

  • (cs)

    TRWTF is hardwiring the number of milliseconds of delay, yeah?

  • (cs)

    TRWTF is setting a property internally (Scenario.delay) rather than returning its value, yeah?

  • (cs)

    TRWTF is what appears to be a global variable (Scenario.delay), yeah?

  • (cs)

    TRWTF is an inline if statement, yeah?

  • (cs)

    TRWTF is spelling "sceptic" with a 'k', yeah?

  • anonymous (unregistered)

    TRWTF is a function that does nothing but take a value of one type ("YES") and overwrite a public value of another type (10000). Apparently the developers invoking this function can't be trusted to put sane values in Scenario.delay, so now they're just supposed to give a "YES" or "NO". Not to worry, since they can overwrite it with whatever they want if they just forgo the use of this useless function...

  • (cs) in reply to powerlord
    powerlord:
    Nagesh:
    dkf:
    The_Assimilator:
    So, TRWTF is the author for not knowing that using == to compare Java Strings for equality flat-out doesn't work.
    No, TRWTF is that neither the author of the code nor the author of the grist for the article know about the equals() method. It's only one of the most introductory things taught to anyone who uses Java. (Also, it doesn't handle all the other kinds of string that might mean that things ought to be switched on, but we'll ignore that for now…)

    equals in 1.6 does not handle Unicode. try to equal two character in Devnagari and you will know what I mean.

    That sounds like a bug since Java Strings are stored as UTF-16 internally (likely Big Endian across all platforms for consistency, but I'd have to consult the standard). They were originally USC-2 in early Java versions, but switched to UTF-16 when it became apparent that 16-bit characters still weren't large enough to store all the characters for all the world's languages.

    Has been fixed in 1.7 as far as I know.

  • Anonymous') OR 1=1 (unregistered)

    Just for fun, I wrote a program to try to find some hash collisions with "YES" (which has hash code 87751, as mandated by the Java spec). I've found a few hundred or so so far among the search space of 7-character strings made up of [A-Za-z0-9]. Here's a small, randomly-selected sample:

    3CCAKWA EldSFZQ FNEReZQ mDiVzaR vZLAXqy KIFHESU

    So if anybody ever calls setDelay("3CCAKWA"), they'll be in for a rude surprise. Well, if getting the Scenario.delay set to 10000 ms when they were expecting no change is surprising.

  • duh (unregistered) in reply to Nagesh
    dkf:
    The_Assimilator:
    So, TRWTF is the author for not knowing that using == to compare Java Strings for equality flat-out doesn't work.
    No, TRWTF is that neither the author of the code nor the author of the grist for the article know about the equals() method.

    No kidding. I facepalmed when I read it.

    Nagesh:
    equals in 1.6 does not handle Unicode. try to equal two character in Devnagari and you will know what I mean.

    As long as the Unicode code points are the same, String.equals() works correctly regardless of the language involved.

    When similar but not identical characters are involved, or when multiple combining diacritics are not in the same order between strings, they obviously won't compare equally via .equals().

    Either way, comparing hash codes is not a working solution.

  • Dave (unregistered)

    That's not what skepticism is about, and you know it. Disappointing.

  • (cs)

    TRWTF is even having the delay argument. If you don't want to set it, don't call it.

    Reminds me of this anti-pattern:

    public void DoSomething(bool areYouSure)
{
   if(areYouSure)
   {
      ...
   }
}
  • (cs)

    Does anybody really know what time it is?

  • Fred (unregistered)

    The BuildMaster cannon is right next to the insufferably cute kitten, but it's pointing the wrong way!

  • Jack (unregistered)
    Steve is way too skeptical to just use an equal sign (or two)
    I thought we were supposed to be using three equal signs now?
  • John (unregistered)

    "Passing a string as a parameter instead of a Boolean is something that, possibly, could be forgiven."

    No, it can't.

  • (cs) in reply to Jack
    Jack:
    Steve is way too skeptical to just use an equal sign (or two)
    I thought we were supposed to be using three equal signs now?

    Only in wish-it-was-strongly-typed languages.

  • DWalker (unregistered) in reply to wsm66
    wsm66:
    Does anybody really know what time it is?

    Does anybody really care?

  • (cs) in reply to fa2k
    fa2k:
    OzPeter:
    A man with one watch always knows what time it is. A man with two watches never does.
    This is also applicable to storing multiple copies of the same data.
    A man with one watch knows what time it is, but doesn't know if it's correct.

    A man with two watches either knows what time it is and is reasonably sure that it's correct, or knows that either of the clocks are incorrect

    That's why you need to wear 3 watches.

    MOE: Hey! What's the idea of the three watches?

    CURLY: That's the way I tell the time.

    MOE: How do you tell the time?

    CURLY: This one runs ten minutes slow every two hours. This runs twenty minutes fast every four hours. The one in the middle is broken and stopped at two o'clock.

    MOE: Well, how do you tell the time?

    CURLY: I take the ten minutes on this one and subtract it by the twenty minutes on that one. Then I divide it by the two in the middle.

    MOE: Well, what time is it now?

    CURLY: [takes a clock out of his jacket pocket] Uh, ten minutes to four.

  • thedude (unregistered) in reply to anonymous
    anonymous:
    fa2k:
    A man with one watch always knows what time it is. A man with two watches never does
    A man with one watch knows what time it is, but doesn't know if it's correct.

    A man with two watches either knows what time it is and is reasonably sure that it's correct, or knows that either of the clocks are incorrect

    It doesn't matter how many clocks a man has; what matters is what he sets them by. If he sets them by an authoritative source, he only needs one clock; if he sets them by other non-authoritative clocks, it doesn't matter how many clocks he has because they'll all be just as wrong as the time source he used to set them by.
    This actually has nothing to do with time. It is a statement of human nature. If a person only has one datum they will be filled with a sense of certainty; however, introduce a second datum and the same person will no longer be certain of anything related to the data.

  • (cs) in reply to thedude
    thedude:
    This actually has nothing to do with time. It is a statement of human nature. If a person only has one datum they will be filled with a sense of certainty; however, introduce a second datum and the same person will no longer be certain of anything related to the data.

    That's also a part of statistics called "confidence."

  • (cs) in reply to John
    John:
    "Passing a string as a parameter instead of a Boolean is something that, possibly, could be forgiven."

    No, it can't.

    "No, it can't" is not a rational response to a conditional statement. What you might have meant to say is that it could not even possibly ever be forgiven.

  • objection (unregistered)

    java is an object-oriented language. He's obviously over-ridden .hashcode

Leave a comment on “You Can't Handle the True!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article