Il y a quelques semaines de cela j'ai fait tourner Reshaper 2.0 sur mon code afin de supprimer les namespaces non utilisés, variables initialisées inutilement et autres petites choses, résultant de refactorings successifs sans cleanup.

Tout se passe pour le mieux jusqu'à ce que mon collègue qui développe une partie de l'assembly me dit : "Ton outil c'est très bien mais il a changé la sémantique de ma fonction..."|-|

En effet Resharper avait changé ce type de code:

public enum BufferType
{
    Stream,
    Buffer,
    Undefined
}
public void Read(out int length , out BufferType type)
{
    length = 0;
    type = BufferType.Undefined;
    Byte[] buff = new Byte[256];
    length = this.DoSomething();
    if(...)
       type = BufferType.Stream;
    else
        type = BufferType.Buffer;
}

en

public void Read(out int length , out BufferType type)
{
    Byte[] buff = new Byte[256];
    length = this.DoSomething();
    if(...)
       type = BufferType.Stream;
    else
        type = BufferType.Buffer;
}

Et oui resharper avait supprimé les 2 affectations en début de méthode. Et là commenca une longue et âpre discussion....

Son argumentation était basée sur le fait que l'utilisation du keyword out obligeait de fournir une valeur de retour correcte dans tous les cas. Donc pour le garantir ca il fallait qu'il initialise ces 2 paramètres dès le début de la méthode. Ceci n'est effectivement pas tout à fait faux.

Mais le compilateur C# vérifie que toutes les branches de code de la méthode vont garantir l'affectations des variables out, donc à priori pas besoin d'affecter d'entrée celles-ci.

Et là tombe l'argument massue! Et oui mais en cas d'erreur, plus précisement la méthode DoSomething lève une exception.... Si tu n'as pas affecté tes variables en début de méthode et bien au sortir tes variables ne le seront pas... Je suis resté dubitatif 88|

Comment peut on imaginer initialiser des variables (toutes out quelles soient) lorsqu'une erreur se produit. Lorsqu'une exception est levée (et qu'elle ne peut pas être traitée dans la méthode) c'est forcément une rupture de contrat. Vouloir transporter des informations grâce aux parametres out pour traiter l'erreur est forcément en opposition avec les bonnes pratiques de gestion d'erreur

Donc pour résumer on laisse le compilo faire son travail et en cas d'erreur c'est à l'appelant de traiter l'erreur et donc d'initialiser les valeurs comme son context le lui indique.

D'autres avis sur la question?