Stupidest code of the day

[Joona I Palaste]

Found in my work colleague's code...

List historyList = /* ... */;
double divider = Double.parseDouble("" + historyList.size());

Now I have come to expect that my colleagues are still stupid enough to
use the ""+ trick to convert primitives to Strings, but that someone who
gets paid to write Java code doesn't know that ints widen to doubles
when assigned to double variables, and instead goes to the trouble of
*creating a String object* instead, is amazing!

 

[Chris Uppal]

List historyList = /* ... */;
double divider = Double.parseDouble("" + historyList.size());

Now I have come to expect that my colleagues are still stupid enough to
use the ""+ trick to convert primitives to Strings, but that someone who
gets paid to write Java code doesn't know that ints widen to doubles
when assigned to double variables, and instead goes to the trouble of
*creating a String object* instead, is amazing!

Not to mention having to handle the checked exception...

(I am just about to bite the bullet and start looking for paid employment
again -- so I find such anecdotes encouraging, even heart-warming ;-)

-- chris

 

[Darryl L. Pierce]

Found in my work colleague's code...

List historyList = /* ... */;
double divider = Double.parseDouble("" + historyList.size());

Try this that I found in code that I have to use as work:

Foo foo = (Foo )Foo.class.newInstance();

 

[thufir]

Darryl L. Pierce wrote:
[..]

Foo foo = (Foo )Foo.class.newInstance();

[..]

Why? It's such an arcane way of doing the hum-drum it's doubly
confusing. Is the constructor for Foo private? The cast is
unnecesary, since a Foo's returned anyhow, right?

 

[dar7yl]

Found in my work colleague's code...

List historyList = /* ... */;
double divider = Double.parseDouble("" + historyList.size());

I've seen this construct before in a VB program which I was forced (due to
economic pressures) to try and decipher.
Evidently, this is B.Gates' method of branding his personal stable of
programmers - totally wiping their brains, and rewriting their
semi-autonomous systems to interface with the Windows Foundation Class API.

regards,
Dar7yl

ps, replies to advocacy only, if you please.

 

[Boudewijn Dijkstra]

Darryl L. Pierce wrote:
[..]

Foo foo = (Foo )Foo.class.newInstance();

[..]

Why? It's such an arcane way of doing the hum-drum it's doubly
confusing. Is the constructor for Foo private? The cast is
unnecesary, since a Foo's returned anyhow, right?

Class.newInstance() is declared to return Object, so a cast is needed here.

 

[bugbear]

Try this that I found in code that I have to use as work:

Foo foo = (Foo )Foo.class.newInstance();

I (hope ;-) that no one would write such code,
but such code could result from global
(i.e. project wide) search-and-replaces,
that take no account of context.

Or the programmer could be an idiot, of course.

BugBear

 

[bugbear]

Try this that I found in code that I have to use as work:

Foo foo = (Foo )Foo.class.newInstance();

ooh! ooh! Another thought. Is the
coder trying to bypass the checked exception signature?

BugBear

 

[John C. Bollinger]

Darryl L. Pierce wrote:
[..]

Foo foo = (Foo )Foo.class.newInstance();

[..]

Why? It's such an arcane way of doing the hum-drum it's doubly
confusing. Is the constructor for Foo private? The cast is
unnecesary, since a Foo's returned anyhow, right?

Note the subject line and original post in this thread. The whole point
is that yes, it's a stupid way of achieving the apparent goal. (But not
directly because of the cast; that's just a side effect of choosing
reflection over "new".)


John Bollinger
(e-mail address removed)

 

[John C. Bollinger]

ooh! ooh! Another thought. Is the
coder trying to bypass the checked exception signature?

Would that make the code any less stupid? More deliberate, perhaps, but
not any less stupid in my book.


John Bollinger
(e-mail address removed)

 

[Boudewijn Dijkstra]

ooh! ooh! Another thought. Is the
coder trying to bypass the checked exception signature?

Even if that is true, it is still stupid code.

 

[Ann]

I've seen this construct before in a VB program which I was forced (due to
economic pressures) to try and decipher.
Evidently, this is B.Gates' method of branding his personal stable of
programmers - totally wiping their brains, and rewriting their
semi-autonomous systems to interface with the Windows Foundation Class API.

regards,
Dar7yl

ps, replies to advocacy only, if you please.

How can 'code' be stupid?

stu·pid (st¡¹pîd, sty¡¹-) adjective
stu·pid·er, stu·pid·est
1. Slow to learn or understand; obtuse.
2. Lacking or marked by a lack of intelligence.
3. In a stupor; stupefied.
4. In a dazed or stunned state.
5. Pointless; worthless: a stupid job.

 

[thufir]

The example uses a static factory, I think.
If that's so, does that make static factory methods an example of
reflection?

 

[Virgil Green]

How can 'code' be stupid?

stu·pid (st¡¹pîd, sty¡¹-) adjective
stu·pid·er, stu·pid·est
1. Slow to learn or understand; obtuse.
2. Lacking or marked by a lack of intelligence.
3. In a stupor; stupefied.
4. In a dazed or stunned state.
5. Pointless; worthless: a stupid job.

See 5

 

[anonymous]

Found in my work colleague's code...

List historyList = /* ... */;
double divider = Double.parseDouble("" + historyList.size());

Now I have come to expect that my colleagues are still stupid enough to
use the ""+ trick to convert primitives to Strings, but that someone who
gets paid to write Java code doesn't know that ints widen to doubles
when assigned to double variables, and instead goes to the trouble of
*creating a String object* instead, is amazing!

The code is not optimal, that is for sure. Nice for your colleage to
know you're an Ûbermensch who can easily spot such mistakes. Sorry for
him that his compiler couldn't warn him, but such is Java. Still in it's
teens.
Sorry for my sarcasm. Just spent 15 hours correcting someone else's code
due tomorrow. At least I am decent enough not to spread HIS/HER code all
over the NG.

 

[Darryl L. Pierce]

Darryl L. Pierce wrote:
[..]

Foo foo = (Foo )Foo.class.newInstance();

[..]

Why? It's such an arcane way of doing the hum-drum it's doubly
confusing. Is the constructor for Foo private? The cast is
unnecesary, since a Foo's returned anyhow, right?

All reasons why it's an example of "stupid code". I wasn't suggesting it
as *good* code, just offering it as an example of *stupid* code.

 

[Darryl L. Pierce]

The example uses a static factory, I think.

No, it doesn't.

 

[Darryl L. Pierce]

I (hope ;-) that no one would write such code,

Oh, someone did. It's a real-world example.

but such code could result from global
(i.e. project wide) search-and-replaces,
that take no account of context.

If so, there would've been a "new" somewhere causing a compiler problem.
Even if someone did a SAR, they would've seen that problem and fixed
the construction. But, they didn't. And when I asked the person about
the code, they admitted it was intentional and "just an experiment"...

 

[Darryl L. Pierce]

ooh! ooh! Another thought. Is the
coder trying to bypass the checked exception signature?

Any exceptions thrown by the constructor would then become unhandled and
crash the whole system. No, the person who did it wasn't doing it to get
around an exception (doing so wouldn't give any advantage); they did it
because they thought it would be "c00l".

 

[John C. Bollinger]

The example uses a static factory, I think.
If that's so, does that make static factory methods an example of
reflection?

The example invokes the newInstance() method of the Class object
corresponding to the class of the desired object. This is the
reflective way of instantiating a class, and it is never appropriate to
use it on a class literal (as was done in the example) because if you
know at compile time the class you want to instantiate then you are
better off every time to use the "new" operator instead. The reflective
technique is a beating-around-the-bush way of doing exactly the same
thing, without any of the advantages that a static factory method can
have. It is only appropriate when the specific class to be instantiated
is not known at compile time, e.g. when the class name is read from a
config file.


John Bollinger
(e-mail address removed)