Quelle syntaxe préférez vous?

Version imprimable

Version 1:

Code:

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:

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:

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];

23/11/2011, 14h35
Max

Citation:

Envoyé par BenoitM

Quelle synthaxe préférez vous?

Avant toute chose, je préfère la syntaxe sans H :mouarf:
23/11/2011, 14h41
BenoitM

Arf :oops:

Je sais pas pourquoi je mets toujours un h, ca vient même pas de l'anglais :aie:
23/11/2011, 14h48
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 ;)

Autre :

Code:

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];

23/11/2011, 16h42
GuruuMeditation

Citation:

Envoyé par 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 ;)

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

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:

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).

23/11/2011, 17h27
tomlev

Citation:

Envoyé par 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é.

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

Citation:

Envoyé par StringBuilder

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 :

Citation:

Code:

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...
23/11/2011, 18h37
BenoitM

euh oui dans mon code c'est un || :oops:

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

Citation:

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.

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:

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:

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