Comment On Magic Number Superstition

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.

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

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.

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});


...

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

(This post is  approved)

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.

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

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"))

Object-oriented programming at its finest.



No, really.

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.

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

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.

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.

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

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

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

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

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

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

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.

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*

Grimoire:

ZERO is not actually 0...

for full kroner, #define Z 0

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.

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.

emptyset:

Grimoire:

ZERO is not actually 0...

for full kroner, #define Z 0

Nope, #define Z 7

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

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:

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:

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

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

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

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...)

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.

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

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]

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;
}

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

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

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() ;)

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

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.");
}

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

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

RAY, YOU ARE GAY

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

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

Agreed!

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

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.

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)