The Daily WTF: Curious Perversions in Information Technology

chubertdev · 2014-04-21 Reply Admin

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

return this.value;

2014-04-21 Reply Admin

setDelay("WillWeHaveDinnerTonight")

Woah there big boy, slow down and keep those pants on.

chubertdev · 2014-04-21 Reply Admin

Spewin Coffee:
setDelay("WillWeHaveDinnerTonight")
Woah there big boy, slow down and keep those pants on.

public static void setDelay(String delay) {
   String yes = "YES";
   String dinner = "WillWeHaveDinnerTonight";
   if ((delay.hashCode()) == yes.hashCode()) Scenario.delay= 10000;
   elseif ((delay.hashCode()) == dinner.hashCode()) Scenario.delay= Double.POSITIVE_INFINITY;
}

2014-04-21 Reply Admin

Doodpants:
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".

Which is why it is a REALLY BAD idea to compare those strings with '=='.

In Java, == is REFERENCE EQUALITY, so it works out if the strings are stored at the same memory location (so it is the same string object). Due to internal optimizations in the JVM, it may indeed happen that they are, but it is not guaranteed. If both strings are initialized from constant within the same class file, chances are very good. It may even work with constants in different class files. But if one string is user input, no way.

2014-04-21 Reply Admin

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.

It works, if you're handling Unicode that needs normalization you don't want a String class to do that automatically since there are different ways to normalize.

2014-04-21 Reply Admin

Limeys suck:
It works, if you're handling Unicode that needs normalization you don't want a String class to do that automatically since there are different ways to normalize.

Ah, yes - that's a plausible explanation for the claim. Yeah, equals() is testing equality, not equivalence - two characters might be equivalent in usage, but if they're not the same Unicode codepoint, they're not equal.

random_garbage · 2014-04-21 Reply Admin

Valued Service:
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.

Java has that! You call ReferenceEquals by using the "==" operator, and Equals by calling the Object.equals(Object) method...

Conversely, C# has an operator called "==" which is equivalent to the object.ReferenceEquals(object) method, except for string where it is equivalent to the string.Equals(object) method. Clear as mud...

2014-04-21 Reply Admin

chubertdev:
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)
   {
      ...
   }
}

At first I thought this could be a debugging convenience for if you wanted one call to a method to not do anything, but then I realised you could just comment out the call... WTF indeed.

2014-04-22 Reply Admin

Hello Nagesh, haven't seen you around lately. It's good to see you commenting again. I hope all is well.

Captcha: quis - My brother's name is Quis, short for Quistopher Wobin.

2014-04-22 Reply Admin

chubertdev:
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)
   {
      ...
   }
}

Enlighten me: why is this an antipattern? It makes short work of the calling code:

bool isValid = someDatabaseCall(whatever);
doSomething (whatever);

... which is considerably more maintainable than:

bool isValid = someDatabaseCall(whatever);
if (isValid) {
    doSomething (whatever);
}

particularly if there is a number of different "someDatabaseCall" functions and invocations of "doSomething".

2014-04-22 Reply Admin

I had to compare two arrays once. Zillions of times, because of a "Project Euler" challenge.

I did not find a function to compare arrays, and so I calculated the CRC-32 hash for each array...

By the way: Semper paratus!

2014-04-22 Reply Admin

programmer:
Doodpants:
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".

Which is why it is a REALLY BAD idea to compare those strings with '=='.

In Java, == is REFERENCE EQUALITY, so it works out if the strings are stored at the same memory location (so it is the same string object). Due to internal optimizations in the JVM, it may indeed happen that they are, but it is not guaranteed. If both strings are initialized from constant within the same class file, chances are very good. It may even work with constants in different class files. But if one string is user input, no way.

If

==

is seriously that unpredictable then it's worse than "always returning false" -- if Paula places some unit tests in place that specifically happen to test strings which (for one of the above reasons) evaluate as the same, she will think her code works as expected.

2014-04-22 Reply Admin

C# also has an upper case 'String' keyword that compiles to the same as 'string'.

2014-04-22 Reply Admin

QJo:
If
==
is seriously *that* unpredictable then it's *worse* than "always returning false" -- if Paula places some unit tests in place that specifically happen to test strings which (for one of the above reasons) evaluate as the same, she will think her code works as expected.

Yes, this is one of the warts of Java that bites pretty much all programmers one time or another, despite it being pretty much the first thing that is told when reading up about string equality checking in Java. Rule of thumb for Java, if you are using == for anything but primitives, you are doing something wrong. Exceptions exist, of course, but if you are writing code that is one of those exceptional cases then you generally know the ugly warts of Java pretty well.

Roby McAndrew · 2014-04-22 Reply Admin

Quietust:
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.

Bluebottle: Eccles, what time is it?

Eccles: Hang on, I've got it written down on a piece of paper....It's 6 O'clock!

Bluebottle: Where did you get the piece of paper?

Eccles: I asked a man the time, and he wrote it down for me.

[Pause]

Bluebottle: Eccles, what do you do if someone asks you the time and it's not 6 O'clock?

Eccles: I don't show them the piece of paper !

2014-04-22 Reply Admin

yourName:
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

I think you mean System.String. String could be anything, depending on what namespaces you are including.

2014-04-22 Reply Admin

QJo:
chubertdev:
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)
   {
      ...
   }
}
Enlighten me: why is this an antipattern? It makes short work of the calling code:
bool isValid = someDatabaseCall(whatever);
doSomething (whatever);
... which is considerably more maintainable than:
bool isValid = someDatabaseCall(whatever);
if (isValid) {
    doSomething (whatever);
}
particularly if there is a number of different "someDatabaseCall" functions and invocations of "doSomething".

Ignoring the fact that the two bits of code do different things, the second is much more readable IMHO.

2014-04-22 Reply Admin

tharpa:
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.

There's not even a hair for you to split here. That is exactly what he said. The "even possibly ever be forgiven" part is implied because it is part of the original statement being disputed.

2014-04-22 Reply Admin

random_garbage:
Conversely, C# has an operator called "==" which is equivalent to the object.ReferenceEquals(object) method, except for string where it is equivalent to the string.Equals(object) method. Clear as mud...

It's not that C#'s "==" operator makes an exception for String. Rather, C# supports operator overriding, so any class can override the "==" operator to provide value equality, which String does.

2014-04-22 Reply Admin

Bonus WTF in the source:

Incredibly cute kitten...sorry you can

Using single-quotes for tag data and string apostrophes? Sign me up. Your HTML parser won't be confused at all.

chubertdev · 2014-04-22 Reply Admin

QJo:
chubertdev:
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)
   {
      ...
   }
}
Enlighten me: why is this an antipattern? It makes short work of the calling code:
bool isValid = someDatabaseCall(whatever);
doSomething (whatever);
... which is considerably more maintainable than:
bool isValid = someDatabaseCall(whatever);
if (isValid) {
    doSomething (whatever);
}
particularly if there is a number of different "someDatabaseCall" functions and invocations of "doSomething".

Because the proper code is just having this:

private void DoSomething() { ... }

And if you want to cancel out the reference:

//DoSomething();

Having that extraneous argument is pointless and toxic to your code.

chubertdev · 2014-04-22 Reply Admin

Andrew:
Bonus WTF in the source:
Incredibly cute kitten...sorry you can

Using single-quotes for tag data and string apostrophes? Sign me up. Your HTML parser won't be confused at all.

HTML: forgiveness by default

2014-04-22 Reply Admin

wsm66:
Does anybody really know what time it is?

Yep. A very accurate description of time from the universe's leading expert.

2014-04-22 Reply Admin

There's no way it could be deliberate is there? Like the kind of code I saw when given a task as part of a competition to find all the security vulnerabilities in an application. Some other code would be stopping an unauthorised user sending "yes" but not stopping an unauthorised user working out another string with the same hash code.

2014-04-22 Reply Admin

QJo:
chubertdev:
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)
   {
      ...
   }
}
Enlighten me: why is this an antipattern? It makes short work of the calling code:
bool isValid = someDatabaseCall(whatever);
doSomething(isValid);
... which is considerably more maintainable than:
bool isValid = someDatabaseCall(whatever);
if (isValid) {
    doSomething();
}
particularly if there is a number of different "someDatabaseCall" functions and invocations of "doSomething".

I fixed your code for you, but is there some law that says you MUST store boolean values so that you can use them once and throw them away?

What do you have against this pattern:

if (someDatabaseCall(whatever)) {
    doSomething()
}

And why is any of them "more maintainable" than the others?

2014-04-22 Reply Admin

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

What time is it Eccles?

Eccles: Oh, just a minute - I got it written down here on a piece of paper.
        A nice man wrote the time down for me this morning.

Ahh - then why do you carry it around with you like that.

Eccles: Oouh, if anybody asked me the time.
        Like I can show it better.

Wait a minute Eccles, my good man.

Eccless: What is it fellow?

It's writted on this piece of paper, but it's eight o'clock it's writted.

Eccles: I know that my good fellow. 
        When I asked the feller to write it down it was eight o'clock.

But then, suppose then when someone asked you the time it isn't eight o'clock.

Eccles: Oh, then I don't show it to them.

Ahhhh........ Ts ts ts......
Well, how do you know when it's eight o'clock.

Eccles: I got it written down on a piece of paper!

Ha, I hope I could afford a piece of paper with the time written on.

Eccles: Oouh.

Yeah, Eccles?

Eccles: Yah.

Let me hold that piece of paper to my ear, would you.
...
Yeah, this piece of paper ain't going.

Eccles: What? I have been sold a forgery!

No wonder it stopped at eight o'clock.

Eccles: Oh Dear!

You should get one of these things my grandad's got.

Eccles: Oouh? Oouh!

His friend gave it to him when he retired.

Eccles: Oouh!

It's one of them things, what it is that, wakes you up at eight o'clock, boils the kettiule and poors a cup of tea.

Eccles: Oouh, yes. What it's called?

My Grandma.

Eccles: Oouh. 
        Oh, ah wait a minute! 
        How does she know when it's eight o'clock?

She got it written down on a piece of paper!

Written and performed by members of The Goon Show

2014-04-22 Reply Admin

public static void main(String[] args) { setDelay(null); }

public static void setDelay(String delay) { String yes = "YES"; if ((delay.hashCode()) == yes.hashCode()) Scenario.delay= 10000; }

Exception in thread "main" java.lang.NullPointerException

2014-04-22 Reply Admin

TRWTF is the fact that he uses a setter to set the delay but inside that method he uses an ugly "Scenario.delay= 10000"

2014-04-22 Reply Admin

Excuse my ignorance - What is an example of a perfect hash?

2014-04-22 Reply Admin

Ok, I see a perfect hash for a closed set - how do you create one for an open string?

2014-04-22 Reply Admin

random_garbage:
Valued Service:
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.
Java has that! You call ReferenceEquals by using the "==" operator, and Equals by calling the Object.equals(Object) method...

Conversely, C# has an operator called "==" which is equivalent to the object.ReferenceEquals(object) method, except for string where it is equivalent to the string.Equals(object) method. Clear as mud...

Some operators are more equal than others.

2014-04-22 Reply Admin

The Fury:
yourName:
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
I think you mean System.String. String could be anything, depending on what namespaces you are including.

It doesn't matter. The incredibly cute kitten will eat them all equally. Just wait 'til she throws.

2014-04-22 Reply Admin

I have a file that can handle the true. It's right here ... um ... somewhere ... now where did it go ...

2014-04-22 Reply Admin

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

No, you can't do that, because String is very deliberately a final class.

QJo:
If
==
is seriously *that* unpredictable then it's *worse* than "always returning false"

No, what == does is completely predictable. The "unpredictable" part is whether you're being passed a String which has been intern'ed or not, and if you find yourself asking the question you've probably done something very wrong.

2014-04-23 Reply Admin

[code]if(s1 == s2) // Note: Reference comparison { // Do something }[code]

That's what comments are good for.

2014-04-23 Reply Admin

QJo:
programmer:
Doodpants:
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".

Which is why it is a REALLY BAD idea to compare those strings with '=='.

In Java, == is REFERENCE EQUALITY, so it works out if the strings are stored at the same memory location (so it is the same string object). Due to internal optimizations in the JVM, it may indeed happen that they are, but it is not guaranteed. If both strings are initialized from constant within the same class file, chances are very good. It may even work with constants in different class files. But if one string is user input, no way.

If
==
is seriously that unpredictable then it's worse than "always returning false" -- if Paula places some unit tests in place that specifically happen to test strings which (for one of the above reasons) evaluate as the same, she will think her code works as expected.

It is not unpredictable at all. It means exactly one thing, all the time: are these two values (whether they are references or raw values) exactly the same?

Paula should have been asking whether the two strings contain the same characters instead, if that's what she wanted to know. Her oversight was caused by her failure to RTFM, not because of any inconsistency in the language.

2014-04-23 Reply Admin

QJo:
Enlighten me: why is this an antipattern? It makes short work of the calling code:
bool isValid = someDatabaseCall(whatever);
doSomething (isValid);
... which is considerably more maintainable than:
bool isValid = someDatabaseCall(whatever);
if (isValid) {
    doSomething ();
}
particularly if there is a number of different "someDatabaseCall" functions and invocations of "doSomething".

By what metric is the second version less maintainable? Because it has 6 more characters of code?

Maintainability is adaptability to changing requirements in my opinion. The only scenario where the first is more maintainable would be if you decide you want to ignore the condition in the future and do always nothing or always something, in which case the calling code would become misleading.

Now consider these changes:

You want to add another condition in one particular instance. Do you:

a) add another parameter to the function, forcing every other call to include a redundant "true", or b) wrap it in an "if"?

Or suppose you want to also doSomethingElse() when the condition is true. Do you:

a) add a parameter to doSomethingElse (which is impossible if you don't own the function) and repeat the condition, or b) wrap it in an "if"?

I hope you'll agree that in both cases, option B is preferable, and it would have saved you the trouble if you had just chosen it in the first place.

Nagesh · 2014-04-23 Reply Admin

Nagesh Aficionado:
Hello Nagesh, haven't seen you around lately. It's good to see you commenting again. I hope all is well.
Captcha: quis - My brother's name is Quis, short for Quistopher Wobin.

Thanks for warm welcome!

2014-04-23 Reply Admin

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.

Umm ... no. String.equals compares the characters in each string. Characters are 16 bits to accommodate Unicode. Maybe you have some particular application that doesn't work, but the problem is not String.equals.

2014-04-23 Reply Admin

QJo:
programmer:
Doodpants:
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".

Which is why it is a REALLY BAD idea to compare those strings with '=='.

In Java, == is REFERENCE EQUALITY, so it works out if the strings are stored at the same memory location (so it is the same string object). Due to internal optimizations in the JVM, it may indeed happen that they are, but it is not guaranteed. If both strings are initialized from constant within the same class file, chances are very good. It may even work with constants in different class files. But if one string is user input, no way.

If
==
is seriously that unpredictable then it's worse than "always returning false" -- if Paula places some unit tests in place that specifically happen to test strings which (for one of the above reasons) evaluate as the same, she will think her code works as expected.

Well, I understand the problem, I fell into the trap a few times, like probably every Java programmer in the world.

But suggesting that there's a problem with the design of the language because incorrect code might sometimes work ... that just doesn't hold water.

To take a trivial example, suppose I write "y=x*2" when I should have written "y=x+2". This code will sometimes work: if x=2. Does that mean that there's a flaw with Java's arithmetic operators? No, it just means that I made a coding error that, under the right conditions, will manage to give the right answer. There are lots and lots of ways you can do that. I've probably made thousands of such coding errors.

chubertdev · 2014-04-23 Reply Admin

Jay:
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.

Umm ... no. String.equals compares the characters in each string. Characters are 16 bits to accommodate Unicode. Maybe you have some particular application that doesn't work, but the problem is not String.equals.

+1

if they were the same, they'd be one character.

2014-04-23 Reply Admin

nmclean:
QJo:
Enlighten me: why is this an antipattern? It makes short work of the calling code:
bool isValid = someDatabaseCall(whatever);
doSomething (isValid);
... which is considerably more maintainable than:
bool isValid = someDatabaseCall(whatever);
if (isValid) {
    doSomething ();
}
particularly if there is a number of different "someDatabaseCall" functions and invocations of "doSomething".
By what metric is the second version less maintainable? Because it has 6 more characters of code?

Maintainability is adaptability to changing requirements in my opinion. The only scenario where the first is more maintainable would be if you decide you want to ignore the condition in the future and do always nothing or always something, in which case the calling code would become misleading.

Now consider these changes:

You want to add another condition in one particular instance. Do you:

a) add another parameter to the function, forcing every other call to include a redundant "true", or b) wrap it in an "if"?

Or suppose you want to also doSomethingElse() when the condition is true. Do you:

a) add a parameter to doSomethingElse (which is impossible if you don't own the function) and repeat the condition, or b) wrap it in an "if"?

I hope you'll agree that in both cases, option B is preferable, and it would have saved you the trouble if you had just chosen it in the first place.

"By what metric is the second version less maintainable? Because it has 6 more characters of code?"

Partly. Shorter code is a good reason of itself. In general, shorter code is easier to read, because I don't have to grasp so much material at one time.

But mostly, because it includes a piece of logic only once instead of multiple times. If in the future we decide that some of what this function does should happen all the time while other things are only done when the flag is true, we only need to change the one function, and not every caller.

If someone adds another call to this function, with the parameter, he will know that there is some "are you sure" condition that needs to be checked. Without the parameter he might overlook that fact.

As to your horror stories: Why is having a function with two parameters a big deal? Is it because it's more characters to type when you write the function call? But you just finished saying that "more characters to type" is not a valid criteria for deciding whether code is good or not. I have functions with more than one parameter all the time and it doesn't traumatize me.

2014-04-23 Reply Admin

Jay:
Partly. Shorter code is a good reason of itself. In general, shorter code is easier to read, because I don't have to grasp so much material at one time.
But mostly, because it includes a piece of logic only once instead of multiple times. If in the future we decide that some of what this function does should happen all the time while other things are only done when the flag is true, we only need to change the one function, and not every caller.

If someone adds another call to this function, with the parameter, he will know that there is some "are you sure" condition that needs to be checked. Without the parameter he might overlook that fact.

As to your horror stories: Why is having a function with two parameters a big deal? Is it because it's more characters to type when you write the function call? But you just finished saying that "more characters to type" is not a valid criteria for deciding whether code is good or not. I have functions with more than one parameter all the time and it doesn't traumatize me.

No, the piece of logic is not restricted to one place. You still have to make the database call outside the function. If it is common, then wrap the database call inside another function.

Code is not easier to read by virtue of being shorter. "if condition then action" is very straightforward and understandable. "action(condition)" is less so. If the syntax in question was particularly unwieldy, you might have a point (but even then, writing some kind of "if(condition, action)" helper function would be preferable to baking it into individual functions), but we are talking about a two-character keyword and some braces here.

The fact that there would be more than one parameter is not the "horror story". The problem is that it only exists for certain cases, and in every other case you're including "true" for no other reason than the signature demands it.

Regarding "Without the parameter he might overlook that fact (that something needs to be checked)" -- This should be a red flag to you. You should not be in a situation like this in the first place, where two processes are co-dependent and a caller needs to be responsible for both of them. Again, the check should be part of a self-contained process.

2014-04-23 Reply Admin

this article sucks

it was not funny

you had a long section for a single joke

the real joke is in your pants

2014-04-23 Reply Admin

Terr:
No, what == does is completely predictable. The "unpredictable" part is whether you're being passed a String which has been intern'ed or not, and if you find yourself asking the question you've probably done something very wrong.

I had an unpredictable intern. Please pass me the string.

no laughing matter · 2014-04-24 Reply Admin

TheDailyWTF-tradtions forced me to write this:

public static void setDelay(String delay) {
   String yes = "YES";
   String letTheInternDelayIt = delay.intern();
   if (letTheInternDelayIt == yes) Scenario.delay= 10000; 
}

Adverse effects: Might overflow the intern pool. Still possible: NullPointerException (like in the original).

2014-05-06 Reply Admin

Anonymous') OR 1=1:
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.

It's a little more broken than that. Here's a C program that computes a preimage for any arbitrary String.hashCode() very very quickly, with only printable characters. If I /don't/ restrict myself to printable character's, String.hashCode() becomes very very laughable.

Aren't non-cryptography hashes fun~?

You Can't Handle the True!

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