#3 Test for “unread” objects

[Bart Buil]

Test for “unread” objects

- Description: Warn for locally unread objects
like the eclipse warning for primitive types

- Category: Optimization / Readability

- Bad code:
StringBuilder sb = new
StringBuilder();
Sb.append(“Hello World”);
return;

[Reinier Zwitserloot]

Logged In: YES
user_id=130807

While your bad code example could be turned into:

new StringBuilder().append("Hello World"); without changing
the semantics of the code in any way, there's a good reason
not to do this or warn for it; for simple readability it can be
nicer to split it up. If you have to make multiple calls,
assigning it to a variable may even be the only way.

If you're talking about the above code not actually doing
anything meaningful, that's a different story. The problem here
is - there's not currently any way to identify java.lang.
StringBuilder.append as being a method that doesn't have any
effect outside its internal state.

ie: compare this to:

OutputStream out = new FileOutputStream("test.txt");
out.write("Hello World");
return;

Looks entirely equal to your example of bad code but it's
proper java code (well, it should at least be followed by an out.
close, but the point's obvious). Short of explicitly making a list
of which methods have effects outside their own internal state
(like OutputStream.write) it's not possible to differentiate the
two. A list introduces complications regarding a child class
that DOES have an external effect whereas its parent, which is
used in the declaration of the variable, does not.

Conclusion: I doubt it's possible to even program this code
check.

[Reinier Zwitserloot]

Logged In: YES
user_id=130807

Some extra notes on this feature after discussing it with
RoelS, the amount of methods in the standard java runtime
(java.*) that 'do stuff externally' is actually quite limited;
Thread, Runtime, and a bunch of things in java.io
(InputStream, OutputStream, Reader, Writer, and related
subclasses, and that's about it). It shouldn't be too difficult to
make an internally stored list that enumerates these. That
would make this feature possible again.

To make it extensible, however, you need some sort of
annotation:

public @ExternalEffects void myOwnMethod()
{
new FileOutputStream("out.dat").write(stuff);
}

an issue to think about is what can be considered 'external
effects'. Is writing log statements to System.out an external
effect? I'm guessing it's not. Is writing command line help to
System.out, for a command-line based program, an external
effect? That definitely counts.

So this still needs some analysis but even with overzealous
marking of 'external effects', it can still be a useful code
check, in the sense that stuff like Making a new list, assigning
some objects to it, and then not doing anything at all to it, can
definitely be caught.