Dois-je toujours/jamais/jamais initialiser les champs de l'objet à des valeurs par défaut ?

Question

Question de style de code ici.

J'ai regardé ce qui demande si le CLR .NET va vraiment toujours initialiser les valeurs des champs. (La réponse est oui .) Mais il me semble que je ne suis pas sûr que ce soit toujours une bonne idée de lui faire faire cela. Je pense que si je vois une déclaration comme celle-ci :

int myBlorgleCount = 0;

J'ai l'impression que le programmeur s'attend à ce que le compte commence à zéro et que cela lui convient, du moins dans l'immédiat. D'un autre côté, si je vois juste :

int myBlorgleCount;

Je n'ai aucune idée immédiate si 0 est une valeur légale ou raisonnable. Et si le programmeur commence simplement à le lire et à le modifier, je ne sais pas s'il avait l'intention de commencer à l'utiliser avant de lui attribuer une valeur, ou s'il s'attendait à ce que ce soit zéro, etc.

D'autre part, certaines personnes assez intelligentes, ainsi que l'utilitaire de nettoyage de code de Visual Studio, me disent de supprimer ces déclarations redondantes. Quel est le consensus général à ce sujet ? (Y a-t-il un consensus ?)

J'ai indiqué qu'il s'agissait d'un projet agnostique par rapport à la langue, mais s'il y a un cas particulier où c'est une bonne idée d'aller à contre-courant pour une langue donnée, cela vaut probablement la peine de le signaler.

EDIT : Si j'ai bien précisé que cette question était agnostique par rapport au langage, elle ne s'applique évidemment pas à des langages comme le C, où aucune initialisation de valeur n'est effectuée.

EDIT : J'apprécie la réponse de John, mais c'est exactement ce que je cherche à faire. pas que je recherche. Je comprends que .NET (ou Java ou autre) fera le travail et initialisera les valeurs de manière cohérente et correcte. Ce que je veux dire, c'est que si je vois du code qui modifie une valeur qui n'a pas été précédemment définie explicitement dans le code, je ne sais pas, en tant que responsable du code, si le codeur original voulait que ce soit la valeur par défaut, ou s'il a simplement oublié de définir la valeur, ou s'il s'attendait à ce qu'elle soit définie ailleurs, etc.

Answer 1

Pensez à la maintenance à long terme.

• Gardez le code aussi explicite que possible.
• Ne comptez pas sur des méthodes d'initialisation spécifiques au langage si vous n'y êtes pas obligé. Peut-être qu'une version plus récente du langage fonctionnera différemment ?
• Les futurs programmeurs vous remercieront.
• La direction vous remerciera.
• Pourquoi obscurcir les choses ne serait-ce qu'un peu ?

Mise à jour : Les futurs mainteneurs peuvent venir d'un autre milieu. Il ne s'agit pas de savoir ce qui est "juste", mais plutôt ce qui sera le plus facile à long terme.

Answer 2

Il est toujours prudent de supposer que la plate-forme fonctionne comme elle fonctionne. La plate-forme .NET initialise tous les champs à des valeurs par défaut. Si vous voyez un champ qui n'est pas initialisé par le code, cela signifie que le champ est initialisé par le CLR, et non qu'il n'est pas initialisé.

Cette préoccupation est valable pour les plateformes qui ne garantissent pas l'initialisation, mais pas ici. En .NET, il s'agit plus souvent d'une ignorance du développeur, qui pense que l'initialisation est nécessaire.

---

Un autre vestige inutile du passé est le suivant :

string foo = null;
foo = MethodCall();

J'ai vu ça de la part de personnes qui devraient être mieux informées.

Answer 3

Je pense qu'il est logique d'initialiser les valeurs si cela clarifie l'intention du développeur.

En C#, il n'y a pas de surcharge puisque les valeurs sont toutes initialisées de toute façon. En C/C++, les valeurs non initialisées contiennent des déchets/des valeurs inconnues (ce qui se trouvait dans l'emplacement mémoire), l'initialisation est donc plus importante.

Answer 4

Je pense que cela devrait être fait si cela aide vraiment à rendre le code plus compréhensible.

Mais je pense que c'est un problème général avec toutes les caractéristiques des langues. Mon opinion à ce sujet est la suivante : S'il s'agit d'une caractéristique officielle de la langue, vous pouvez l'utiliser. (Bien sûr, il y a des anti-fonctionnalités qui doivent être utilisées avec précaution ou évitées, comme l'absence de option explicit en Visual Basic ou l'héritage en diamant en C++)

Il fut un temps où j'étais très paranoïaque et où j'ajoutais toutes sortes d'initialisations inutiles, de castings explicites, de blocs try-finally über-paranoïaques, ... J'ai même pensé une fois à ignorer l'auto-boxing et à remplacer toutes les occurrences par des conversions de type explicites, juste "pour être sûr".

Le problème est le suivant : Il n'y a pas de fin. Vous pouvez éviter presque toutes les caractéristiques de la langue, car vous ne voulez pas leur faire confiance.

Rappelez-vous : ce n'est que de la magie jusqu'à ce que vous la compreniez :)

Answer 5

Je suis d'accord avec vous ; c'est peut-être verbeux, mais j'aime voir :

int myBlorgleCount = 0;

Maintenant, je paraphe toujours des cordes :

string myString = string.Empty;

(Je déteste les chaînes nulles.)