Discussion :

[BenoitM]

Version 1:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (value == null && value.Count<1) return null;
if (value.Count == 1) return value[0];
MessageMetier msg = new MessageMetier("Pas de résultat unique",NiveauMessageMetier.Error)
throw new FunctionalException (msg);

Version 2:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
if (value == null && value.Count<1) return null;
elseif (value.Count == 1) return value[0];
else 
{
    MessageMetier msg = new MessageMetier("Pas de résultat unique",NiveauMessageMetier.Error)
    throw new FunctionalException (msg);
}

Version 3:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
if (value == null && value.Count<1) return null;
else if (value.Count > 1) 
{
    MessageMetier msg = new MessageMetier("Pas de résultat unique",NiveauMessageMetier.Error)
    throw new FunctionalException (msg);
}
else return value[0];

[Max]

Quelle synthaxe préférez vous?

Avant toute chose, je préfère la syntaxe sans H

[BenoitM]

Arf

Je sais pas pourquoi je mets toujours un h, ca vient même pas de l'anglais

[tomlev]

La première, parce que les else ne servent à rien. Avant j'aurais peut-être fait autrement, mais depuis que j'utilise Resharper il me signale tout le temps les else redondants

[StringBuilder]

Autre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
if (value == null && value.Count < 1)
    return null;
 
if (value.Count > 1) 
{
    MessageMetier msg = new MessageMetier("Pas de résultat unique",NiveauMessageMetier.Error)
    throw new FunctionalException (msg);
}
 
return value[0];

[GuruuMeditation]

La première, parce que les else ne servent à rien. Avant j'aurais peut-être fait autrement, mais depuis que j'utilise Resharper il me signale tout le temps les else redondants

Même chose. Resharper c'est bien pratique pour éliminer ce genre de petites crasses Comment j'ai pu vivre sans toutes ces années ?

[StringBuilder]

Un else inutile, je doute que ça change grand chose en terme de temps d'exécution.

Même pire, je suis près à parier qu'avec un compilateur avancé tel que celui de .NET, il va être retiré.

En revanche, pour améliorer la lisibilité du code, un bon else des familles avec une belle indentation, ça permet parfois de tiquer immédiatement "ah mais oui biensûr !"

Du coup, je ne suis pas catégorique en ce qui concerne la suppression des else inutiles : pas toujours je pense.

J'ai déjà eu à maintenir du code indenté de façon anarchique, et en l'absence de blocs convenablement indentés, c'est vide une galère immonde.

Outre l'aspect lisibilité du code, j'ai aussi deux interrogations à propos des return toutes les deux lignes...

Qu'en est-il des performances ?
-> J'ai lu, il y a longtemps, peut-être à propos de VB6, qu'il vallait mieux faire un return en fin de fonction plutôt que X répartis dans le code, c'était mieux pour les performances.
Est-ce applicable à .NET ?

Et la maintenance alors ?
-> Outre la lisibilité, le code doit être maintenable, et notamment pouvoir évoluer. Comment ajouter par exemple une trace "Valeur de retour : {0}" si dès qu'on connaît la valeur, on quitte la méthode ?

Pour ces deux raisons, je m'efforce toujours de faire quelque-chose de ce genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
// Je préfère gérer les erreurs de paramètres en début de fonction
if (value.Count > 1) 
{
    MessageMetier msg = new MessageMetier("Pas de résultat unique",NiveauMessageMetier.Error)
    throw new FunctionalException (msg);
}
 
// J'initialise une variable de retour avec une valeur par défaut
int retval = DEFAULT_VALUE; // Dans notre exemple, c'est "null"
 
if (value != null && value.Count == 1)
{
    retval = value[0];
}
 
// Ici, je peux faire autant d'évolutions ou traces que je le désire
return retval;

Perso, je ne trouve pas ça moins lisible.

A noter que le retval, en VB à l'époque, n'était pas obligatoire (en VB, on ne retourne pas une valeur : on affecte une valeur à la fonction, puis on quitte la fonction. Le même mécanisme existe aussi en C# si je ne m'abuse, mais est assez boudé, ce que je comprends (pas très lisible, d'autant qu'au niveau perfs, ça change absolument rien).

[tomlev]

Un else inutile, je doute que ça change grand chose en terme de temps d'exécution.

Même pire, je suis près à parier qu'avec un compilateur avancé tel que celui de .NET, il va être retiré.

Effectivement, en terme de perf ça change rien...

En revanche, pour améliorer la lisibilité du code, un bon else des familles avec une belle indentation, ça permet parfois de tiquer immédiatement "ah mais oui biensûr !"

Bah c'est assez subjectif... perso j'aime mieux sans le else. Par contre je mets l'instruction qui suit le if sur une nouvelle ligne, je trouve ça plus clair.

Pour ce qui est de l'indentation foireuse, Visual Studio peut corriger ça avec juste un raccourci clavier...


Par contre je viens de voir ça dans le code d'origine :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (value == null && value.Count<1) return null;

Il faut faire un OU, pas un ET ! Avec ce code, si value est null, c'est une NullReferenceException garantie...

[BenoitM]

euh oui dans mon code c'est un ||

j'ai finalement écrit le même code que StringBuilder de 15h51

pour mettre au début du code les "return" invalides et à la fin le return valide

J'ai lu, il y a longtemps, peut-être à propos de VB6, qu'il vallait mieux faire un return en fin de fonction plutôt que X répartis dans le code, c'était mieux pour les performances.

Je préfère avoir un return au milieu et donc savoir que dans ce cas je peux arrêter de lire le reste du code.

[Graffito]

Aucune

Je préfère une solution semblable à celle proposée par stringbuilder, surtout parceque les return au milieu d'une fonction sont à éviter

Donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
if (value!=null &&  value.Count>1)
{ 
   MessageMetier msg = new MessageMetier("Pas de résultat unique",NiveauMessageMetier.Error) ;
   throw new FunctionalException (msg);
}
return value == null || value.Count<1 ? null : value[0];

Concernant l'utilisation des return, je conseille par expérience de n'en mettre qu'un seul en fin de procédure. Ne l'ayant pas fait pendant mes dix premières années de déveloopement, puis ayant adopté cette pratique depuis longtemps maintenant, je ne peux que m'en féliciter.

Par analogie à Pascal dans lequel le retour se fait via le mot réservé "Result", nous nommons dans toutes les fonctions (non void) la variable de retour "Result". En permettant d'identifier immédiatement la variable de retour quelquesoit la fonction, cela facilite la maintenance.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public int sum(int a, int b) 
{
  int Result=a+b ;
  return Result ;
}