J'ai reçu un lien vers la documentation officielle d'Oracle: https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
où il est dit:
Les valeurs par défaut
Il n'est pas toujours nécessaire d'attribuer une valeur lorsqu'un champ est déclaré. Les champs déclarés mais non initialisés seront définis par défaut par le compilateur. De manière générale, cette valeur par défaut sera zéro ou nulle, selon le type de données. S'appuyer sur de telles valeurs par défaut, cependant, est généralement considéré comme un mauvais style de programmation.
Je veux souligner cette partie:
S'appuyer sur de telles valeurs par défaut, cependant, est généralement considéré comme un mauvais style de programmation.
Mais, oh boy, c'est, je dirais, une partie fondamentale de la spécification du langage sachant que les variables d'instance ont des valeurs par défaut. Pourquoi diable c'est une mauvaise pratique de programmation si elle est largement utilisée même dans le code source des bibliothèques Java SE?
la source
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.public abstractméthode dans une interface.privateméthodes dans une interface n'auraient aucun sens etabstractsont implicites.Réponses:
Le texte cité est:
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.
la source
Simple: s'appuyer sur des valeurs par défaut ne communique pas l'intention.
Vouliez-vous vraiment que ce champ commence par 0, ou avez-vous oublié d'attribuer une valeur?!
Et bien sûr, une référence null est la moitié des deux choses dont vous avez besoin pour exécuter une exception nullpointer.
Enfin, l'utilisation des valeurs par défaut implique que vous avez des champs non finaux. Que vous évitez autant que possible.
Le seul contre-argument est: pourquoi écrire des choses que vous n'avez pas à faire? Mais je pense que les inconvénients énumérés trompent cela, attribuer ainsi 0 à un champ explicitement est mieux que de le laisser au compilateur.
la source
L'idée est que si vous vous fiez à une valeur par défaut, il n'est pas immédiatement clair pour quiconque lit le code si vous l'avez délibérément laissé comme valeur par défaut, ou si vous avez simplement oublié de l'assigner.
Le code source Java n'est pas vraiment quelque chose sur lequel vous devriez vous fier comme exemple de pratique de codage exemplaire. Il existe de nombreux cas où de telles règles sont violées (parfois intentionnellement pour des améliorations mineures des performances, et parfois accidentellement ou parce que le style accepté a changé au fil des ans.)
la source