Pourquoi l'utilisation de conjonctions dans les noms de méthode est-elle une mauvaise convention de dénomination? [fermé]


12

Dans mon équipe, nous travaillons en étroite collaboration avec quelques architectes logiciels. Ils approuvent toutes les décisions de conception de nos projets, font des revues de code, etc.

Nos projets consistent principalement en des fonctionnalités backend implémentées en PHP utilisant le framework Symfony 2. Donc, syntaxiquement, le code, les conventions de dénomination et la structure du projet semblent presque identiques à ce à quoi Java ressemblerait (Symfony 2 encourage une telle structure). Je le mentionne car les conventions spécifiques à Java s'appliquent également dans notre cas (si possible).

Récemment, ils ont suggéré quelque chose que je trouve très étrange: toutes les méthodes devraient avoir des conjonctions dans leur nom, par exemple getEntityOrNull, setValueOrExceptionetc.

Une telle convention de dénomination me semble très mal, mais je ne peux pas trouver d'arguments concrets ou d'articles / pages en ligne qui contestent spécifiquement cela.

Les seules choses que j'ai trouvées sont:

  • ces informations doivent être présentes dans les annotations de la méthode, comme @returnou@throws
  • l'utilisation de conjonctions ("et", "ou" etc.) dans les noms de méthode suggère généralement que le principe de responsabilité unique n'est pas correctement respecté

Quels sont les autres arguments concrets contre cette convention de dénomination?


en général, vous ne pouvez pas
moucher

5
the use of conjunctions ("and", "or" etc.) in method names usually suggest that the Single Responsibility Principle is not properly respectedCe n'est pas le cas pour les exemples que vous avez énumérés, où la conjonction est utilisée pour clarifier le mécanisme utilisé pour gérer les échecs, pas pour indiquer qu'il peut faire une chose ou une autre. Même la fonction la plus étroitement définie peut avoir des conditions d'échec légitimes, par exemple le saut d'une pile vide.
Doval, le

4
Considérez: (1) en utilisant "facultatif" plutôt que "ou null". "GetOptionalEntity" sonne mieux à mon oreille que "GetEntityOrNull". (2) la bibliothèque de classes de base .NET utilise la convention que si vous avez deux méthodes qui ne diffèrent que par ce qu'elles lancent, nommez celle qui ne peut pas lancer "TryBlah". Par exemple, Int32.TryParseet Int32.Parse- les deux analysent une chaîne en un entier, mais le premier retourne un booléen indiquant le succès et le second renvoie en cas d'échec.
Eric Lippert, le

Je n'utiliserais pas de suffixe pour la variante de lancement, mais j'utiliserais un pour la variante de retour nul. Peut - être Try..., ...OrNull, ...OrDefault. @EricLippert Ce n'est pas la seule convention en .net. Considérez Singlevs SingleOrDefault, qui est très proche OrNulldu PO suggéré.
CodesInChaos

Réponses:


11

Ils le font probablement en raison de conflits de noms. Je suppose que vous ne pouvez pas avoir deux méthodes nomméesgetEntity , l'une qui peut éventuellement déclencher une exception et l'autre qui revient null. Par conséquent, vous devez les nommer en conséquence.

Pour ma part, je n'aime pas la pratique d'avoir de nombreuses façons différentes d'appeler la même méthode, sauf si elle effectue une modification que seule cette classe particulière peut effectuer.

En d'autres termes, si getValueOrNullest simplement en train d'appeler getValueOrException, de capturer l'exception, et dans ce cas de revenir null, cela peut être effectué par l'appelant. Il encombre la classe avec des méthodes qui ne contribuent vraiment à rien d'utile. Je préférerais plutôt le getValue, et je sais que cela lève l'exception. Mieux encore, je préférerais savoir que toutes les méthodes get peuvent potentiellement générer des exceptions, et aucune ne retourne à la nullplace de sorte que le comportement soit uniforme tout au long de mon projet, ou inversement, toutes potentiellement retournentnull , et sachez que l'appelant devrait lever une exception si qui étaient souhaités.

Cependant, il est également vrai que vous n'êtes pas responsable de cela. Mon conseil est d'en parler, mais ne vous inquiétez pas des petites choses. En fin de compte, la responsabilité de telles conventions de dénomination incombe à leurs épaules, qu'elles suivent ou non vos conseils, et parce que ce sont leurs fesses en jeu, je pense que c'est leur prérogative de dire non, à mon humble avis.


Si vous ne deviez en choisir qu'un, il est préférable de revenir null(ou mieux encore, un type Facultatif / Peut-être) car le lancer est relativement cher. L'écriture d'un assistant qui vérifie si une valeur n'est pas valide et lève n'ajoute pas beaucoup de frais généraux. Cependant, lorsque vous voulez la version sans lancer, avaler l'exception ne vous rendra pas le coup de performance que vous avez pris en le jetant.
Doval, le

1
@Doval Bon point, et peut-être plus important encore, les exceptions devraient être exceptionnelles . Si vous lancez souvent des exceptions, vous ne les utilisez pas correctement. Le seul problème avec le retour nullest que cela nullpeut en fait être un retour valide dans certains cas et vous devrez donc dévier de la norme et lever une exception dans de tels cas.
Neil

3

Bien que l'utilisation de conjonctions indique souvent une violation du SRP, dans ce cas, elle indique simplement la valeur de retour du type de données algébrique d'un pauvre qui peut être l'une des deux valeurs, soit nullune valeur de «succès».

Ils utilisent une sorte de notation hongroise pour compenser les faiblesses du système de types, à savoir le manque de types non annulables. En d'autres termes, il n'y a aucun moyen de spécifier dans votre @returnannotation que la fonction ne retournera jamais null, et inversement, il n'y a aucun moyen de spécifier dans votre @returnannotation que la fonction peut éventuellement retourner null.

De plus, je pense que les @throwsannotations ne sont pas obligatoires en php, donc l'absence d'annotation n'indique pas l'absence d'exception, bien que cela soit mieux résolu en rendant l'annotation obligatoire dans votre guide de style.

Compte tenu de ces limites de la langue que vous utilisez, ce n'est pas un style totalement déraisonnable.


2

Dans mon code, je crée parfois des paires de méthodes avec des noms comme getEntity () et getEntityOrNull (). Le nom indique clairement le comportement attendu. Si getEntity () ne trouve aucune entité, une exception est levée. getEntityOrNull () renverra un null.

Ce faisant, le code appelant devient un peu plus clair. Si le code appelant doit avoir une entité, getEntity fera l'affaire. Si l'entité est une sorte de chose facultative, alors getEntityOrNull est la méthode de choix.

La même chose pourrait être accomplie avec une seule méthode mais qui transfère ensuite une partie de la charge au programme appelant. Vous devez toujours tester une valeur nulle ou vous avez besoin d'un bloc try / catch. Quoi qu'il en soit, c'est du code supplémentaire qui doit être dupliqué à chaque appel de la méthode.

Si vos architectes n'utilisent pas ces sortes de paires de méthodes, alors oui, je remettrais en question la nécessité du suffixe.

Jamais vraiment vu une méthode setValueOrException. Je ne peux pas penser à un bon cas d'utilisation commun pour cela.

Vous pourriez envisager de demander aux architectes pourquoi. Ceux que je connais sont toujours heureux d'expliquer leurs décisions. Souvent dans les moindres détails (et parfois atroces).


Que getEntity lèvera une exception en cas d'échec n'est pas du tout clair pour moi, je m'attendrais à un simple NULL.
Elise van Looij

1

Vos deux arguments sont solides. Mais si ce sont eux qui sont chargés de décider de la convention de dénomination, essayez de ne pas vous sentir trop mal à l'idée que ce soit quelque chose avec lequel vous n'êtes pas d'accord.

Pendant que vous y êtes, vous devez les convaincre de ne pas utiliser les parties "get" et "set" à moins que ces méthodes ne définissent ou obtiennent directement une variable membre.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.