Needless casts?

[Joona I Palaste]

I've seen a few casts in the Java code some of my colleagues write I
think are totally needless. For example, various upcasts. For example:

public class Core {
public void update(Component c) { /* ... */
}
}

public abstract class Component { /* ... */
}

public class MagicComponent extends Component { /* ... */
public void doThings() { /* ... */
new Core().update((Component)this);
}
}

That I could think would be explained by reminding people (who are
too stupid to look at the class declaration) that MagicComponent
extends Component, but then there are casts that cast an object to
the class it already is:

Item i = new Item();
component.add((Item)i);

and I once even saw this:

String error_notInitialized = (String)"Not initialized.";

What's the point in *that*?

(All code above has been paraphrased. The syntax is preserved but
the semantics aren't. The real code is under NDA.)

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The large yellow ships hung in the sky in exactly the same way that bricks
don't."
- Douglas Adams

 

[Joona I Palaste]

That I could think would be explained by reminding people (who are
too stupid to look at the class declaration) that MagicComponent
extends Component, but then there are casts that cast an object to
the class it already is:

Item i = new Item();
component.add((Item)i);

I meant, of course, cast a *reference* to the class it already is. You
can't cast objects in Java, only references. Sorry about the sloppy
terminology.

 

[Tony Morris]

I've seen a few casts in the Java code some of my colleagues write I
think are totally needless. For example, various upcasts. For example:

public class Core {
public void update(Component c) { /* ... */
}
}

public abstract class Component { /* ... */
}

public class MagicComponent extends Component { /* ... */
public void doThings() { /* ... */
new Core().update((Component)this);
}
}

That I could think would be explained by reminding people (who are
too stupid to look at the class declaration) that MagicComponent
extends Component, but then there are casts that cast an object to
the class it already is:

Item i = new Item();
component.add((Item)i);

and I once even saw this:

String error_notInitialized = (String)"Not initialized.";

What's the point in *that*?

(All code above has been paraphrased. The syntax is preserved but
the semantics aren't. The real code is under NDA.)

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The large yellow ships hung in the sky in exactly the same way that bricks
don't."
- Douglas Adams

Yes, I see it often too, but what is your point ?
Are you questioning whether or not it is poor form ?
I am of the firm opinion that an explicit (and therefore, redundant) upcast
is "up there" with all the other abuses of the language.
In fact, I have my development environment raise a flag when it occurs.

If it was your own code, it creates needless clutter, that hinders
readability for no advantage.
If it is somebody else's code it also causes a distrust in the competency of
that developer to design before implementation (as well as other things,
such as understanding fundamental language semantics).
I do not, and never will, condone the EAIAD* software development paradigm,
albeit it being used so often.

*Excuses After Implementation After Design

I'd fail this code in a comprehensive code review.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
IBM Australia - Tivoli Security Software
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Roedy Green]

new Core().update((Component)this);
}
}

That I could think would be explained by reminding people (who are
too stupid to look at the class declaration) that MagicComponent
extends Component, but then there are casts that cast an object to
the class it already is:

That sort of a cast says "I am only using this object qua Component.
If I try to get smart and use methods of MagicComponent, javac will
smite me down."


You are quite correct though they all could be removed, and it would
normally generate the same byte code, with exceptions such as this:


print( magicComponent );
and
print ( (Component) magicCompenent);

will match different signature versions of print. (Component) forces
use of the generic version.

 

[Roedy Green]

Item i = new Item();
component.add((Item)i);

This is merely documentation on what sort of animal is being added and
a verification that it indeed is. It has no runtime overhead.

Try reading someone else's code that has 50+ collections NONE of which
document anywhere what sort of critter is stored in each. It is like
reading a sentence like this:

Somebody did a thing to partya and stored a whatchamacalit in the
thingabamob filed under some key or other.

 

[Roedy Green]

String error_notInitialized = (String)"Not initialized.";

Yucch! That drives me almost as nuts as

String error_notInitialized = (String) new String("Not initialized.");

or

if ( ( a == true) == true )

see http://mindprod.com/jgloss/newbie.html

 

[Chris Uppal]

Roedy Green wrote:

String error_notInitialized = (String) new String("Not initialized.");

Just by the way, the

new String("blah")

construct is semantically meaningful and even, albeit *very* occasionally,
useful. It guarantees that the String is a unique object, rather than possibly
sharing its identity with another, coincidentally existing, String literal
somewhere in the execution.

The cast of course, is simply an abomination....

-- chris

 

[VisionSet]

Yucch! That drives me almost as nuts as

String error_notInitialized = (String) new String("Not initialized.");

or

if ( ( a == true) == true )

I can sort of understand someone uneccesarily writing:

if ( ( a = true) == true )

but what possible excuse is there for:

if ( ( a == true) == true )

 

[Chris Uppal]

but what possible excuse is there for:

if ( ( a == true) == true )

Hereditary insanity ?

"if (a == true)" is bad enough...

-- chris

 

[Chris Uppal]

print( magicComponent );
and
print ( (Component) magicCompenent);

will match different signature versions of print. (Component) forces
use of the generic version.

Which is why such casts are more than just redundant, they are actively *wrong*
unless they are intended to control method resolution.

-- chris

 

[Timo Kinnunen]

I can sort of understand someone uneccesarily writing:

if ( ( a = true) == true )

but what possible excuse is there for:

if ( ( a == true) == true )

Multiple small changes could result in that. From if(!b) to if(!b==true) to
if((b==false)==true) to if((a==true)==true).

Sometimes if(someLongCondition==false) is more readable than
if(!someLongCondition), IMHO.

 

[Joona I Palaste]

I can sort of understand someone uneccesarily writing:

if ( ( a = true) == true )

but what possible excuse is there for:

if ( ( a == true) == true )

As I mentioned in another thread, some of my colleagues actually prefer
to write:

boolean v = false;
if (value >= minimum) {
if (value <= maximum) {
v = true;
}
}
return v;

to writing:

return value >= minimum && value <= maximum;

I of course prefer the latter to the former, and even the Sun Java
code conventions agree with me.

 

[Roedy Green]

by the way, since "a" is a boolean expression already the way you
should write that is:

if ( a )

 

[Roedy Green]

return value >= minimum && value <= maximum;

In mathematics that expression would be written

minimum <= value <= maximum

So I mirror that as closely as possible in java with:

if ( minimum <= value && value <= maximum )


If you are consistent about that it is always clear which is the lower
and upper bound.

 

[Filip Larsen]

Joona I Palaste wrote

return value >= minimum && value <= maximum;

I of course prefer the latter to the former, and even the Sun Java
code conventions agree with me.

Range tests also look good when you do them like

return minimum <= value && value <= maximum;

which can be read like "minimum <= value <= maximum" and that makes for
good proofreading.


Regards,

 

[Icemerth]

Joona I Palaste wrote


Range tests also look good when you do them like

return minimum <= value && value <= maximum;

which can be read like "minimum <= value <= maximum" and that makes for
good proofreading.


Regards,

y