Re: unused statics?
On 1/24/2013 8:16 PM, Lew wrote:
Arne Vajh?j wrote:
Patricia Shanahan wrote:
Arne Vajh???j wrote:
Lew wrote:
Why was it assigned its default value redundantly?
Sometimes it improves readability.
Not this time.
I am not able to say whether a certain construct improve
readability or not based on a single line.
And as I explained later then my main criteria is
what the other lines do.
Do you use mind reading to see what the other lines are
or?
Was it the OP's intention?
To write readable code? I assume so!
Why not let the OP answer?
It is rather common to comment on comments here.
I think that it is easier to read code that are consistent
in initialization.
A class where all fields are initialized in declaration,
a class where all fields are initialized in constructor or a
class where all fields get default value is easy to understand
in my opinion.
If 1/3 of fields are are initialized in declaration, 1/3 in
constructor and 1/3 get get default value then the reader will
spend the first 10 minutes trying to guess what the developers
reason for doing so is.
There are engineering reasons for each of the three choices. Sometimes
those reasons vary within the same class. So then you use comments to
explain the divergence. Whenever I deem it worthwhile to take the tiny
performance hit of redundantly assigning the same value to a member twice,
I comment why it's done.
So I think you'd find that readable, too.
But having to comment on something that can be written so no
comments are necessary does not seem optimal. And one could still
wonder why.
Here's why you need more than one way to do things:
public class Foo<T>
{
private final Class<T> rttt;
private boolean initialized = false; // explicitly initialized to emphasize the logic
private Bar bar;
public Foo(Class<T> rttt)
{
if (rttt == null) {throw new IllegalArgumentException("null rttt"); }
this.rttt = rttt;
}
public void setBar(Bar bar)
{
this.bar = bar;
}
public Bar getBar()
{
return bar;
}
}
I see no readability problems with this.
I do.
Not a big problem - far from.
But the asymmetry still gives a desire to spend more time to
read the code to try and understand why it was done this way.
Arne