The Daily WTF: Curious Perversions in Information Technology

2005-10-20 Reply Admin

Alex Papadimoulis:

caseMgr.setAssetId(result.getResults().elementAt(0).toString());
caseMgr.setTypName(result.getResults().elementAt(1).toString());
caseMgr.setValCode(result.getResults().elementAt(2).toString());
caseMgr.setValDesc(result.getResults().elementAt(Integer.parseInt("3")).toString());

Is there a 10 character limit to the method names in Java?

As for the rest, I cannot think of any excuses doing it this way. A real WTF.

rogthefrog · 2005-10-20 Reply Admin

Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

quamaretto · 2005-10-20 Reply Admin

Now, wait a second, haven't you heard of Trinary Java? To use decimal, he would have had to prepend each decimal number with 0d, and that would have looked silly. Lay off of him.

2005-10-20 Reply Admin

This is probably one of those situations where the client complained that the original code was too efficient, so the developper went back and tried to slow it down. I think I spoke to him, and he was saying that if the client still wasn't satisified, is next step was going to be something like:

run(aPhoneNumber, "substring", new Object[]{new Integer(Integer.parseInt("3"))}, new Integer(Integer.parseInt("3"))], new Class[]{int.class, int.class});

...

travisowens · 2005-10-20 Reply Admin

Smart guy to use 3 as the cutoff because if he went to 4, then he would have to hardcode Pi

(This post is [image] approved)

2005-10-20 Reply Admin

It's like the stories I hear that go like this:

A non-software engineers will write a 500 line function. Later, he is told the function is not necessary. His response is to spend another 40 lines undoing what the previous 500 lines did.

Joshie · 2005-10-20 Reply Admin

I was going to post a real comment about this, but I just can't stop laughing: But numbers three and above ... hard-coding those was just a flat-out bad practice. Everyone knows that you should use strings for those ...

2005-10-20 Reply Admin

rogthefrog:
Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

Double check the parenthesis again. He's calling toString() on elementAt(Integer.parseInt("3"))

2005-10-20 Reply Admin

Object-oriented programming at its finest.

No, really.

2005-10-20 Reply Admin

This happens when you have to follow brain dead coding standards and design rules. I bet that poor guy had been hit over his head with a 200 page style guide, because he once hard coded a number greater 3. This was his little revenge: Code in full compliance with the rules, so no quality clown could reject the code.

kipthegreat · 2005-10-20 Reply Admin

Anonymous:
This happens when you have to follow brain dead coding standards and design rules. I bet that poor guy had been hit over his head with a 200 page style guide, because he once hard coded a number greater 3. This was his little revenge: Code in full compliance with the rules, so no quality clown could reject the code.

I think (hope) that this is what actually happened...

2005-10-20 Reply Admin

He was probably on a project that used Checkstyle to look for magic numbers and used parseInt() as a stupid end-run around the Checkstyle rules. He should have defined int constants for what each element meant (ASSET_ID_INDEX = 0, TYPE_NAME_INDEX = 1), etc.

2005-10-20 Reply Admin

Anonymous:
He should have defined int constants for what each element meant (ASSET_ID_INDEX = 0, TYPE_NAME_INDEX = 1), etc.

This is one coding practice often see ignored. It's a bother if it's only ints that aren't defined constants, but it's a mess if it's strings that show up in 20 places in code.

2005-10-20 Reply Admin

If I close my eyes and count to Integer.parseInt("10")).toString(), maybe it will go away. ;^)

Grimoire · 2005-10-20 Reply Admin

Anonymous:
He was probably on a project that used Checkstyle to look for magic numbers and used parseInt() as a stupid end-run around the Checkstyle rules. He should have defined int constants for what each element meant (ASSET_ID_INDEX = 0, TYPE_NAME_INDEX = 1), etc.

Or even constants like ZERO, ONE, TWO, THREE, FOUR, etc. For full marks, make sure that ZERO is not actually 0...

2005-10-20 Reply Admin

What, no try/catch block around the parseInt call!

2005-10-20 Reply Admin

I guess we've found the author of the code. 8)

Really, in an environment like "lalala" described, I would do the same.

kipthegreat · 2005-10-20 Reply Admin

Anonymous:
He was probably on a project that used Checkstyle to look for magic numbers and used parseInt() as a stupid end-run around the Checkstyle rules. He should have defined int constants for what each element meant (ASSET_ID_INDEX = 0, TYPE_NAME_INDEX = 1), etc.

Maybe he could have used (1+1+1) for 3.....

2005-10-20 Reply Admin

Anonymous:
I guess we've found the author of the code. 8)
Really, in an environment like "lalala" described, I would do the same.

Ugh. Just in case: this was supposed to be a reply to "lalala" comment.

emptyset · 2005-10-20 Reply Admin

Anonymous:
It's like the stories I hear that go like this:

A non-software engineers will write a 500 line function. Later, he is told the function is not necessary. His response is to spend another 40 lines undoing what the previous 500 lines did.

ain't that the truth. *zing*

emptyset · 2005-10-20 Reply Admin

Grimoire:
ZERO is not actually 0...

for full kroner, #define Z 0

brazzy · 2005-10-20 Reply Admin

rogthefrog:
Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

Actually, it isn't the same in ANY spec-conforming Java implementation. The former will create a different object each time it is executed, while the latter is taken from the class's constant pool. Or, in code:

"3" == "3"
is true, while
"3" == Integer.parseInt("3").toString()
is false.

Of course, it hardly ever makes sense to deliberately create non-identical strings with the same content, and if you really have to, that's what the String(String) constructor is for.

RevMike · 2005-10-20 Reply Admin

rogthefrog:
Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

Well, of course. He is trying to account for localization.

masklinn · 2005-10-20 Reply Admin

emptyset:
Grimoire:
ZERO is not actually 0...

for full kroner, #define Z 0

Nope, #define Z 7

kipthegreat · 2005-10-20 Reply Admin

brazzy:
rogthefrog:
Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

Actually, it isn't the same in ANY spec-conforming Java implementation. The former will create a different object each time it is executed, while the latter is taken from the class's constant pool. Or, in code:

"3" == "3"
is true, while
"3" == Integer.parseInt("3").toString()
is false.

Of course, it hardly ever makes sense to deliberately create non-identical strings with the same content, and if you really have to, that's what the String(String) constructor is for.

I think when he said "isn't the same", he meant it like most people would take it, that it represents the same set of characters (i.e. .equals()), which would be true.
"3".equals("3") is true
"3".equals(Integer.parseInt("3").toString()) is also true

RevMike · 2005-10-20 Reply Admin

brazzy:
rogthefrog:
Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

Actually, it isn't the same in ANY spec-conforming Java implementation. The former will create a different object each time it is executed, while the latter is taken from the class's constant pool. Or, in code:

"3" == "3"
is true, while
"3" == Integer.parseInt("3").toString()
is false.

Of course, it hardly ever makes sense to deliberately create non-identical strings with the same content, and if you really have to, that's what the String(String) constructor is for.

However...

"3" == Integer.parseInt("3").toString().intern()

is true

kipthegreat · 2005-10-20 Reply Admin

kipthegreat:
brazzy:
rogthefrog:
Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

Actually, it isn't the same in ANY spec-conforming Java implementation. The former will create a different object each time it is executed, while the latter is taken from the class's constant pool. Or, in code:

"3" == "3"
is true, while
"3" == Integer.parseInt("3").toString()
is false.

Of course, it hardly ever makes sense to deliberately create non-identical strings with the same content, and if you really have to, that's what the String(String) constructor is for.

I think when he said "isn't the same", he meant it like most people would take it, that it represents the same set of characters (i.e. .equals()), which would be true.
"3".equals("3") is true
"3".equals(Integer.parseInt("3").toString()) is also true

Of course it should be noted that the WTF code never actually did Integer.parseInt("3").toString()

kipthegreat · 2005-10-20 Reply Admin

kipthegreat:
kipthegreat:
brazzy:
rogthefrog:
Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

Actually, it isn't the same in ANY spec-conforming Java implementation. The former will create a different object each time it is executed, while the latter is taken from the class's constant pool. Or, in code:

"3" == "3"
is true, while
"3" == Integer.parseInt("3").toString()
is false.

Of course, it hardly ever makes sense to deliberately create non-identical strings with the same content, and if you really have to, that's what the String(String) constructor is for.

I think when he said "isn't the same", he meant it like most people would take it, that it represents the same set of characters (i.e. .equals()), which would be true.
"3".equals("3") is true
"3".equals(Integer.parseInt("3").toString()) is also true

Of course it should be noted that the WTF code never actually did Integer.parseInt("3").toString()

Now that I think about it, Integer.parseInt("3").toString() would never compile... Integer.parseInt("3") is an int, which is primitive, so .toString() couldn't compile....

rogthefrog · 2005-10-20 Reply Admin

Anonymous:
rogthefrog:
Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

Double check the parenthesis again. He's calling toString() on elementAt(Integer.parseInt("3"))

Oh right, my mistake. It all makes sense now.

* rogthefrog goes off to change all his code to reflect this superior design pattern

2005-10-20 Reply Admin

Why don't you just make ten louder and make ten be the top number and make that a little louder?

kipthegreat · 2005-10-20 Reply Admin

Anonymous:
Why don't you just make ten louder and make ten be the top number and make that a little louder?

is that a spinal tap reference? (i've never seen it...)

2005-10-20 Reply Admin

But these go to eleven!

Seriously, I suspect what's really happened here is someone did a find/replace for some stuff and hit "Replace All" without meaning to. I have personally done that. I accidentally did s/""/String.Empty/g in some .NET code once and never found the ensuing havoc until much later.

2005-10-20 Reply Admin

Anonymous:
But these go to eleven!

I accidentally did s/""/String.Empty/g in some .NET code once and never found the ensuing havoc until much later.

Wow! Coding through search&replace - gotta love that :)

NonDev

OneFactor · 2005-10-20 Reply Admin

Anonymous:
If I close my eyes and count to Integer.parseInt("10")).toString(), maybe it will go away. ;^)

But keep in mind that counting to Integer.parseInt("010") is not the same as counting to 010. [H]

OneFactor · 2005-10-20 Reply Admin

for (int i = 0; isTrue(i < Integer.parseInt("3")); i++) {
 switch i:
 case 0: System.out.print("W"); break;
 case 1: System.out.print("T"); break;
 case 2: System.out.print("F"); break;
}

2005-10-20 Reply Admin

This is not true. The J2SE API Specification does not guarantee that an object is created for this method, nor does it guarantee that an object is not created. The argument that is passed to the method is taken from the constant pool (see VM Spec 4) and an "object is created" (it is indeed created - JLS 3.10.5 iirc) in the same way that one is created for all other String literals - simply, both code samples create an object at class load time (the class containing that constant pool), not one or the other. You may have been confusing that Integer.parseInt returns "something else" (an int) that is not the instance representing the passed String literal itself.

Here is a related topic to the one I believe was attempting to be highlighted.
http://jqa.tmorris.net/GetQAndA.action?qids=68&showAnswers=true

Oh, and if you want to argue, I implement the spec. as my day job :) but I'm always up for a constructive debate.

2005-10-20 Reply Admin

I thought I pressed the "quote" button.
I was referring to:

Actually, it isn't the same in ANY spec-conforming Java implementation. The former will create a different object each time it is executed, while the latter is taken from the class's constant pool. Or, in code:

"3" == "3"
is true, while
"3" == Integer.parseInt("3").toString()
is false.

Of course, it hardly ever makes sense to deliberately create non-identical strings with the same content, and if you really have to, that's what the String(String) constructor is for.

2005-10-20 Reply Admin

Anonymous:
This is not true. The J2SE API Specification does not guarantee that an object is created for this method, nor does it guarantee that an object is not created. The argument that is passed to the method is taken from the constant pool (see VM Spec 4) and an "object is created" (it is indeed created - JLS 3.10.5 iirc) in the same way that one is created for all other String literals - simply, both code samples create an object at class load time (the class containing that constant pool), not one or the other. You may have been confusing that Integer.parseInt returns "something else" (an int) that is not the instance representing the passed String literal itself.

Here is a related topic to the one I believe was attempting to be highlighted.
http://jqa.tmorris.net/GetQAndA.action?qids=68&showAnswers=true

Oh, and if you want to argue, I implement the spec. as my day job :) but I'm always up for a constructive debate.

I have nothing constructive to say. I simply want to note that this proves that it is one fscked-up language.

ok
dpm

2005-10-20 Reply Admin

kipthegreat:

Now that I think about it, Integer.parseInt("3").toString() would never compile... Integer.parseInt("3") is an int, which is primitive, so .toString() couldn't compile....

Yes, this should clearly be solved with a
(new Integer(Integer.parseInt("3")).toString() ;)

2005-10-20 Reply Admin

I just think this programmer grew up listening to Schoolhouse Rock. Because everyone who listened to that knows that "3 is a magic number."

OpBaI · 2005-10-21 Reply Admin

OneFactor:
for (int i = 0; isTrue(i < Integer.parseInt("3")); i++) {
 switch i:
 case 0: System.out.print("W"); break;
 case 1: System.out.print("T"); break;
 case 2: System.out.print("F"); break;
}

You will never understand.

int errors = 0; for (int i = 0; isTrue(i < Integer.parseInt("3")); i++) { switch(i) { default: if(i == 0) { System.out.print("W"); } else if(i == 1) { System.out.print("T"); } else if(i == 2) { System.out.print("F"); } else { errors += 1; } } } if(isTrue(errors == Integer.parseInt("12")) { throw new SwitchCaseFailure("Invalid arguments."); }

llxx · 2005-10-21 Reply Admin

"Magic numbers"? This example looks a bit too artificial.

Regarding hard-coded values, what I do is just hard-code them in when they aren't likely to be changed and use defines when they are. Converting a string to an int? I hardly see the advantages of this scheme.

Style guidelines don't help much if taken to the extreme.

ray · 2005-10-21 Reply Admin

Not to be funny or anything Alex, but that is the lamest WTF I've seen on this site. Running out of WTF's???

petvirus · 2005-10-21 Reply Admin

RAY, YOU ARE GAY

ray · 2005-10-21 Reply Admin

BLOW ME!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

NineSisters · 2005-10-21 Reply Admin

Come on. The poor code being written by 12 years old kids is not fun any more. It's just the same kind of crap any inexperienced programmer writes in his first learning year. :D

ray · 2005-10-21 Reply Admin

Agreed!

ray · 2005-10-21 Reply Admin

Thats why in java we use .equals() to compare the content of the object. ;)

ray · 2005-10-21 Reply Admin

brazzy:
rogthefrog:
Maybe Integer.parseInt("3").toString() isn't the same as "3" in his implementation of Java.

Actually, it isn't the same in ANY spec-conforming Java implementation. The former will create a different object each time it is executed, while the latter is taken from the class's constant pool. Or, in code:

"3" == "3"
is true, while
"3" == Integer.parseInt("3").toString()
is false.

Of course, it hardly ever makes sense to deliberately create non-identical strings with the same content, and if you really have to, that's what the String(String) constructor is for.

Forgot the quote button. :)

Anyway as I said, this is the reason we have the .equals() funtion in java, as it allows us to compare the contents of an object as opposed to "= =" that will compare the objects themselves to see if they are in fact the same object.

ammoQ · 2005-10-21 Reply Admin

llxx:
"Magic numbers"? This example looks a bit too artificial.

Regarding hard-coded values, what I do is just hard-code them in when they aren't likely to be changed and use defines when they are. Converting a string to an int? I hardly see the advantages of this scheme.

Style guidelines don't help much if taken to the extreme.

While I cannot confirm this particular example, I'm know programmers who have comparable habits. For example, they say "global variables are bad" and the build incredible complex constructs to imitate the semantics of global variables (but of course it's not better at all, since it is the semantic that makes global variables bad)

Magic Number Superstition

Leave a comment on “Magic Number Superstition”