./21 > Non il ne doit pas. Je suis d'accord que c'est chiant, j'ai déjà rencontré le problème plusieurs fois, mais si tu réfléchis un peu:
Quand tu code en C ou C++, si tu n'initialise pas une variable, ben elle a une valeur indéterminée... En C# c'est pareil, donc rien de méchant jusque là.
Si tu fais un test du type de celui que tu montre en ./1 , dans le meilleur des cas ton test donnera toujours le bon résultat.
Mais dans le cas non prévu, voire impossible, si il venait à ce produire quand même... En C/C++ si par ta variable était un pointeur (ça peut aussi avec d'autres variables mais c'est plus par effet indirect) tu as de grandes chances de faire ce que les linuxiens appellent une erreur de segmentation. En C# c'est pareil. Sauf que .NET ne peut et ne doît jamais crasher, tout doit passer par des exceptions managées. (D'ailleurs je crois pas qu'il y ait de bug qui ferait planter JIT, enfin sait-on jamais ^^)
Et le seul moyen de se prémunir contre les états du programmes indéterminés (même si ils sont, ou tout au moins semblent, impossibles à attendre... on sait jamais), ben c'est d'avoir des valeurs déterminées.
Donc on peut utiliser des valeurs par défaut automatiques, c'est le cas des membres de classe en C#. Mais dans une fonction c'est souvent contre-productif, à plus forte raison si ta fonction est petite et appelée souvent...
Du coup le choix de laisser l'utilisateur choisir ses valeurs est logique. Mais d'un autre coup tu ne peux plus te permettre de laisser passer des valeurs potentiellement non initialisées.
Au final tu dois écrire légèrement plus de code... Mais je pense que tu y es gagnant