Relying on default field initialisation - is bad programming style?
Why on earth this is a bad programming practice
The idea is if you rely on a default value, then it's not immediately clear to anyone reading the code if you deliberately left it as the default value, or you simply forgot to assign it.
...if it is widely used even in Java SE libraries source code??
The Java source code isn't really something you should rely on as an example of exemplary coding practice. There's many cases where such rules are violated (sometimes intentionally for minor performance improvements, and sometimes accidentally or because accepted style has changed over the years.)
The quoted text is:
"Relying on such default values, however, is generally considered bad programming style."
Cynically: "it is generally considered that" is often a way of saying that the author hasn't tried to find an authoritative source for the statement being presented.
In this case the assertion is clearly questionable. Evidence: 5 out of 5 Java Style Guides sampled do NOT say anything about whether you should or should relying on default values:
- Google Java Style Guide
- Twitter Java Style Guide
- Java Programming Style Guide - JavaRanch (dubious)
- Java Code Style Guidelines - Cornell University CS.
- The OpenJDK Draft Java Style Guide
(Note, my methodology for sampling was to look at the first 5 distinct Google search hits for "java style guide". Then I searched each document for "default". This is not a thorough analysis, but it serves to make my point.)
OK. So does it really aid readability of Java code?
This is debatable.
On one hand, a novice Java programmer who hasn't learned about default initialization may be baffled about where the zeros or nulls are coming from. But if they bother to look for an explicit initialization and find there isn't one, that should be sufficient to cause them to read a tutorial or book to find out about default initialization. (You would hope!)
On the other hand, we don't normally expect novice Java programmers to be maintaining production code-bases. For an experienced Java programmer a redundant initialization does not improve readability. It is (at best) noise.
To my mind, the only thing that is achieved by a redundant initialization of a field is to signal to a future reader of your code that you have thought about the the initial value. (As @GhostCat expressed it, default initialization does not communicate intent.)
But conversely if I was that reader, I would not necessarily trust the thinking of the code author. So the value of this "signal" is also questionable.
What about reliability?
In Java it makes no difference. The JLS specifies that default initialization does occur for fields. And conversely, for local variables it is a compilation error to try to use a variable that has not been definitely initialized.
In short, the runtime behavior of a variable that is not explicitly initialized is entirely predictable.
By contrast in languages like C or C++ where variables may not be initialized, the behavior is unspecified, and can lead to crashes, and differences in behavior on different platforms. The case for always explicitly initializing variables is much stronger here.
What about performance?
It should make no difference. The JIT compiler should be able to treat a redundant initialization and default initialization as the same.
Simple: relying on default values does not communicate intent.
Did you really want that field to start with 0, or did you forget to assign a value?!
And of course, a null reference is half of the two things you need to run into a nullpointer exception.
Finally, using defaults implies that you have non final fields. Which you avoid where possible.
The only counter argument is: why write down things that you don't have to? But I think the listed disadvantages trumpet that, thus assigning 0 to a field explicitly is better than leaving it to the compiler.