Le texte cité est:
"Cependant, se fier à de telles valeurs par défaut est généralement considéré comme un mauvais style de programmation."
Cyniquement: "il est généralement considéré que" est souvent une façon de dire que l'auteur n'a pas essayé de trouver une source faisant autorité pour la déclaration présentée.
Dans ce cas, l'affirmation est clairement discutable. Preuve: 5 guides de style Java sur 5 échantillonnés ne disent PAS si vous devez ou devez vous fier aux valeurs par défaut:
(Remarque, ma méthodologie d'échantillonnage consistait à examiner les 5 premiers résultats de recherche Google distincts pour "guide de style java". Ensuite, j'ai cherché chaque document pour "par défaut". Ce n'est pas une analyse approfondie, mais cela sert à faire valoir mon point de vue. )
D'ACCORD. Cela facilite-t-il vraiment la lisibilité du code Java?
C'est discutable.
D'une part, un programmeur Java novice qui n'a pas appris l'initialisation par défaut peut être dérouté quant à la provenance des zéros ou des null. Mais s'ils prennent la peine de chercher une initialisation explicite et en trouvent qu'il n'y en a pas, cela devrait être suffisant pour leur faire lire un tutoriel ou un livre pour en savoir plus sur l'initialisation par défaut. (Vous espérez!)
D'un autre côté, nous ne nous attendons pas normalement à ce que les programmeurs Java novices maintiennent des bases de code de production. Pour un programmeur Java expérimenté, une initialisation redondante n'améliore pas la lisibilité. C'est (au mieux) du bruit.
À mon avis, la seule chose qui est réalisée par une initialisation redondante d'un champ est de signaler à un futur lecteur de votre code que vous avez pensé à la valeur initiale. (Comme @GhostCat l'a exprimé, l'initialisation par défaut ne communique pas l'intention.)
Mais inversement, si j'étais ce lecteur, je ne ferais pas nécessairement confiance à la pensée de l'auteur du code. La valeur de ce "signal" est donc également discutable.
Et la fiabilité?
En Java, cela ne fait aucune différence. Le JLS spécifie que l' initialisation par défaut ne se produit pour les champs. Et inversement, pour les variables locales, c'est une erreur de compilation que d'essayer d'utiliser une variable qui n'a pas été définitivement initialisée.
En bref, le comportement à l'exécution d'une variable qui n'est pas explicitement initialisée est entièrement prévisible.
En revanche, dans des langages comme C ou C ++ où les variables peuvent ne pas être initialisées, le comportement n'est pas spécifié et peut entraîner des plantages et des différences de comportement sur différentes plates-formes. Le cas d'une initialisation toujours explicite des variables est beaucoup plus fort ici.
Et la performance?
Cela ne devrait faire aucune différence. Le compilateur JIT doit pouvoir traiter une initialisation redondante et une initialisation par défaut comme identiques.
private int count = 0;
est un code qui ne fait rien, et un code qui ne fait rien est un fouillis. C'est comme importer des classes depuis java.lang, ou déclarer une classe avecextends Object
.