Est-ce une bonne pratique de nommer la variable renvoyée «résultat»? [fermé]

44

Est-ce une bonne pratique d'appeler la variable renvoyée par une méthode avec un nom de variable result?

Par exemple:

public Zorglub calculate() {
    Zorglub result = [...]
    [...]
    return result;
}

Ou devrais-je le nommer par son type?

public Zorglub calculate() {
    Zorglub zorglub = [...]
    [...]
    return zorglub;
}

J'ai vu les deux à l'état sauvage, si je dois en choisir un, quelles raisons pourraient me faire préférer l'ancien ou le dernier (ou un nom plus approprié)?

Je pense principalement à Java.

Nicolas Raoul
la source
73
J'ai également vu ofTheJediutilisé à cette fin. Pas une recommandation, juste dire que je l'ai vu. Zorglub ofTheJedi = //...; return ofTheJedi;
7
J'appelle généralement cela "retval" (valeur à renvoyer) mais c'est plus ou moins la même chose que "résultat", sur lequel je mettrais mon vote.
Zeta Two
5
Tout le monde a une réponse différente, ils sont tous similaires, mais différents et valables, la question n'est pas volontairement subjective, mais les réponses le sont. C'est plus un sondage.
ZJR
16
Je dirais que "résultat" en tant que variable convient, mais "calculer" en tant que fonction ne l'est absolument pas.
Kaz Dragon
2
Travaillez-vous avec beaucoup d'anciens programmeurs Delphi?
Peter Turner

Réponses:

48

S'il s'agit d'une variable de méthode, cela dépend vraiment de la lisibilité.

Comme vous avez déjà le nom du type à la fois dans la déclaration de variable et dans le type de retour de méthode, vous pouvez également utiliser result- cela décrit le rôle de la variable.

Oded
la source
40

La lecture croisée est facilitée si la variable est nommée result. Cela rend votre intention claire.

mouviciel
la source
2
+1 C'est le point principal. Je sais ce que le résultat signifie dans n'importe quel contexte en jetant un coup d'œil au code.
Xeoncross
1
Je suis d'accord, utiliser le type de variable ne vous aide pas à comprendre que vous allez le renvoyer. Dans ces exemples simples, il est plus facile de voir le retour sans faire défiler ni regarder, mais il est plus rapide de savoir dès le départ quelle est la valeur renvoyée de la fonction. Il est également important de l'initialiser, comme dans l'exemple.
Nycynik
17

Si j'ai besoin d'une variable de retour (ce qui se produit rarement en réalité), je l'appelle rettoujours et la définit toujours juste en dessous de la fonction head. La fonction a déjà un nom, qui dit tout sur ce qu’elle retourne.

Si j'ai myFunctionje pourrais nommer de variable de retour myFunctionReturnValueà dire exactement la même chose, que je dois dire explicitement chaque fois. Puisque les fonctions doivent généralement être courtes, une telle explicité n’est pas nécessaire. Et même si je perds le fil, je peux sauter à la déclaration et atterrira juste en dessous de la définition de la fonction.

Mais tout autre nom, qui n'implique pas implicitement (comme retou result) ou explicitement (comme myFunctionReturnValueou myFunctionResult), qu'il s'agisse de la variable de retour des fonctions actuelles est trop générique.

Dans votre deuxième exemple, zorglubc'est un choix terrible. Tout ce que la déclaration me dit vraiment, c'est que vous avez créé une variable dont le nom est égal à l'annotation de type trouvée juste à côté du nom. C'est aussi utile que int someIntou Zorglub z.

Dans votre premier exemple, lorsque je regarde le code, je vois d’abord le nom de la fonction, qui me dit que cette fonction calcule a Zorglub. En lisant la deuxième ligne, je vois "ok, voici le zorglub, qui va être renvoyé, mais il ne peut évidemment pas être renvoyé immédiatement et est donc stocké dans la resultvariable" (en remarque: si vous êtes ne va pas réaffecter la valeur, alors il vaut mieux déclarer la variable finale pour la communiquer), et ensuite je pense "alors voyons ce qui se passe avant qu’elle ne soit renvoyée". A la différence dans le premier exemple , je ne ai pas besoin de lire vraiment plus loin que de savoir que c'est la variable, qui va être de retour et que je veux suivre dans le corps de la fonction si je veux comprendre.

Vous voudrez peut-être lire sur la programmation Spartan , qui est plutôt liée à votre question.

back2dos
la source
8
+1 pour "zorglub est un choix terrible". Il n’existe aucune raison terrestre d’avoir un nom de variable, quel que soit le contexte, identique au nom du type (moins le capital initial). La déclaration vous indique le type de la variable - nommer votre variable après votre type ne vaut pas mieux que d'appeler vos variables x1, x2, x3, etc. Le nom de toute variable doit exprimer son utilité ou son utilité. Mon nom préféré pour une variable dans ce cas particulier est toReturn - car la variable fait référence à l'objet à renvoyer. En fait, beaucoup de mes noms de variables commencent par "to".
Dawood dit réintégrer Monica
21
@ DavidWallace - c'est trop fort d'un absolu. J'ai une classe appelée Container. Si j'ai une méthode qui modifie la quantité, je dirais var container = getContainer(id); container.Quantity += 1; que c'est certainement lisible si le contexte de la méthode n'opère que sur un seul conteneur, et c'est tout ce que cela fait. L'appeler theContainerWeAreGoingToAdjustTheQuantityOfest simplement ridicule.
Scott Whitlock
4
@ David, je ne suis pas d'accord. Prenons une situation où vous avez plusieurs variables locales, chacune d'un type différent (disons Utilisateur, Gestionnaire et Département). Et supposons que la tâche consiste à relier l'utilisateur au département et à l'équipe du responsable. IMHO il est parfaitement correct d'appeler cette instance utilisateur simplement user(plutôt que userToJoinThisDepartmentAndManager? Ou quel serait votre choix?)
Péter Török
10
Nippick mineur: je déteste voir "ret" ou "va" ou d'autres variantes abrégées de result / returnValue. "résultat" n'est pas très long, et personne n'a besoin de conserver des caractères.
Kristopher Johnson
2
@KristopherJohnson: "résultat" n'est pas très long, mais cela ne signifie pas non plus "valeur de retour". Les valeurs de retour ne sont pas toujours des résultats de calculs et, inversement, les résultats de calculs ne sont pas toujours des valeurs de retour. Je suppose que vous pourriez nommer votre valeur de retour returnValue, mais retest traditionnelle, tout comme intet char.
Ruakh
12

Dans votre deuxième exemple, vous fusionnez le type du résultat avec ce qu'il est .

Zorglub zorglub;

me dit juste que c'est un Zorglub, deux fois. Trois fois si je me donne la peine de lire le type de retour de méthode. cependant,

double variance;

par exemple, me donne un indice sur ce que la valeur de retour des moyens , en termes de sémantique du programme. Cela peut être ou ne pas être plus clair que de simplement l'appeler result, en fonction de la taille de la méthode - c'est un jugement pour chaque méthode IMO.

Inutile
la source
8

Si vous jouez avec de nombreux objets Zorglub dans vos méthodes, vous « pouvez » faire une erreur et retourner le mauvais, et / ou vous pourriez être tenté de nommer les autres zorglub1, zorglub2etc.

Si vous le nommez result, il n’ya aucune chance que vous fassiez une telle erreur. De plus, je trouve que c'est un bon nom; J'ai aussi vu returnedValueou returnedObjectplusieurs fois, c'est aussi clair bien qu'un peu long.

Jalayn
la source
5

Personnellement, je ne suis pas tout à fait à l'aise d'utiliser resultun nom de variable. Très bien, cela me dit que la valeur associée est le résultat de certains calculs - mais je suppose que cela est vrai pour environ (ou plus) 90% des variables / champs utilisés dans un programme.

De plus, comme plusieurs autres réponses l'ont noté, il peut être utilisé pour marquer la valeur à renvoyer d'une méthode / fonction. Cependant, si mes méthodes sont courtes, concentrées sur une seule chose et sur le même niveau d'abstraction, je n'aurai pas beaucoup de variables locales et il sera facile de voir quelle méthode retournera.

Je préfère donc garder mes méthodes courtes et propres et nommer mes variables pour exprimer le sens de la valeur qu'elles tiennent, plutôt que son rôle local dans la méthode englobante. Cependant, (par exemple dans le code existant) Zorglub resultpeut être certainement plus facile à comprendre que Zorglub zorglub.

Péter Török
la source
12
Ce n'est pas appelé resultparce que c'est le résultat d' un calcul; on l'appelle resultparce que c'est le résultat de ce calcul. Cela fonctionne également comme son sens OMI, même si ce n’est pas le sens le plus spécifique possible. Exprimer le sens est d’or, mais l’ intention et les idiomes peuvent aussi être précieux. Dans ce cas, c'est un peu un compromis.
Supr
@Supr: Quel nom utiliseriez-vous pour décrire le résultat d'un autre calcul, qui ne sera utilisé que dans la ou les prochaines déclarations (par exemple if (result >= 0) numChars+=result; else break;, et dont le sens sera évident dans le calcul en question?) À mon avis, la valeur qui seront être renvoyés de cette fonction doit être appelée ret, alors que la valeur qui a été renvoyé par la dernière fonction appelée devrait être result. Notez que cela resultpeut être plus significatif qu'un nom plus long si la valeur de retour de la fonction peut par exemple représenter une quantité ou un code d'erreur.
Supercat
@supercat, je l’appellerais en fonction de la nature du calcul ou de l’utilisation de la valeur. Même s'il n'est utilisé que dans le calcul suivant, il facilite encore la lisibilité s'il est bien nommé. Dans votre exemple, je n'ai aucune idée de ce que signifie resultou de ce que le code fait réellement à un niveau supérieur. Je devrais me référer à l'endroit où il est placé pour voir d'où vient sa valeur et ce que c'est. Quelque chose comme addedCharsou matchedCharsqui serait plus transparent et aiderait à révéler ce que fait le code, sans exiger de jongler mentalement entre ceci et ce qui le concerne result = ...:)
Supr
@ Supr: Le problème est que dans de nombreux cas, différentes plages de valeurs de retour peuvent signifier différentes choses. Par exemple, une routine pour lire un paquet dans un tampon de taille spécifiée peut renvoyer un nombre d'octets si un paquet a été reçu, ou un nombre négatif pour indiquer qu'un paquet était (et est toujours) en attente et qu'il est trop gros pour le tampon, ou un très grand nombre négatif pour indiquer une autre erreur. Stocker le retour dans result, puis le comparer à ces critères semblerait plus naturel que d'essayer de trouver un nom descriptif qui les couvre tous.
Supercat
@supercat, utiliser retau lieu de resultme convient bien. À mon avis, c'est un peu moins clair, car il est abrégé et non pas comme un nom, mais s'il est utilisé de manière cohérente, il est équivalent à result.
Supr
1

Personnellement, j'utilise le nom resultde la valeur à renvoyer depuis la fonction / méthode. Cela rend explicite que c'est la valeur à renvoyer. Nommer par type ne semble pas utile, car il peut y avoir plus d’une variable de ce même type.

Juraj Blaho
la source
Uhm, le fait qu'il soit écrit 'retour' avant qu'il soit retourné est suffisamment explicite? Vous devriez décrire ce que vous allez en faire, maintenant le "comment". Pourquoi ne pas appeler cela total, résultat ou quelque chose d'autre, alors votre code sera prêt à "renvoyer total" ou similaire ...
Dave
@ Dave Pas nécessairement, surtout si vous avez quelques objets du même type qui doivent tous être retournés, le but de la méthode est de déterminer lequel est le bon à retourner.
Andy
@Andy, je vois ce que vous voulez dire, mais en réalité, je ne peux pas imaginer écrire une fonction comme celle-là. Si c'est la raison pour laquelle vous écrivez une fonction comme celle-là, il semblerait qu'il faille la décomposer en fonctions plus petites et plus compréhensibles.
Dave
1

Quelle est la différence? c'est juste 2 mots différents qui feront la même chose, donc le vrai problème est de savoir lequel vous semble le plus clair?

Le "résultat" ou "zorglub".

Je préférerais utiliser ZorglubResultcomme démarreur pour voir que le résultat est Zorglub plus facile à comparer avec les autres résultats que vous pourriez avoir et que c'est un résultat, comme vous pouvez le voir.

Berker Yüceer
la source
1

dois-je le nommer par son type?

Non jamais. Ceci s'appelle Systems Hungarian et est trivialement dépassé par l'idée d'utiliser un programme capable d'afficher le type de toute variable à tout moment.

DeadMG
la source
1

Chaque fois que vous devez nommer quelque chose dans le code, vous devez fournir des noms descriptifs, significatifs et lisibles. Le cas d'une variable de retour est un exemple particulièrement intéressant de cas où les gens ont tendance à faire preuve de complaisance en matière de dénomination.

Si vous avez une fonction clairement nommée et que vous n'avez besoin que d'une seule ligne de code, vous pouvez ignorer entièrement le nom. Rendre vos méthodes courtes et simples est toujours l’idéal que vous devriez viser. Cependant, il est parfois nécessaire de compléter une fonction avec plusieurs lignes de code. Dans ces cas, il est toujours conseillé de nommer votre variable en fonction du but de votre fonction.

Si le but de la fonction est de renvoyer le résultat d'un calcul ou d'un algorithme de décision, le resultnom que vous utilisez pour la variable convient-il parfaitement, mais que se passe-t-il si votre fonction renvoie un élément d'une liste? Que se passe-t-il si votre fonction remplit un autre objectif qui n'a rien à voir avec les mathématiques ou les listes? Dans ces cas, il est préférable de fournir à la variable un nom explicite expliquant la raison pour laquelle la fonction a été créée. Bien sûr, vous pouvez simplement utiliser result si vous le souhaitez, car il s'agit d'un nom qui ne risque pas d'entrer en conflit, mais du point de vue de la lisibilité, il est plus logique de nommer votre variable de manière plus significative et contextuelle.

S.Robins
la source
0

J'aime les combiner, montre ce que c'est et qu'il est destiné à être retourné.

Donc, dans votre exemple, il serait resultZorglub

si ce que c'est n'a pas vraiment d'importance alors ce serait juste le résultat (pas resultString)

KeesDijk
la source
Pas mal, mais je suppose que vous devrez renommer votre variable si le type de retour change. Avec IDE moderne, je suppose que tout est fait en un ou deux clics.
Jalayn
@Jalayn Oui, mais si le type était gardé en dehors du nom, il s'agirait d'un changement qui ne devrait pas être effectué du tout. (Si une méthode est suffisamment longue pour qu'un nom simple ne soit pas clair, elle est probablement trop longue et devrait être refactorée.)
Donal Fellows
@DonalFellows Je suis tout à fait d'accord avec toi. Moins il y a de changements lors de la mise à jour à partir du référentiel source, mieux c'est.
Jalayn
D'accord, d'accord pour dire que lorsque vous modifiez le type de retour, vous pouvez oublier de le modifier également dans le nom de la variable, ce qui pose un problème. Jusqu'à présent, cela n'a jamais été un problème pour moi. J'aime toujours montrer la double intention dans le nom, mais avec un code d’intention plus petit, qui montre déjà très bien, il pourrait aussi être exagéré. Vous m'avez convaincu. Si je ressens le besoin d'appeler mes variables de cette manière à partir de maintenant, je vais le refactoriser jusqu'à ce que je n'en ressente plus le besoin. Merci
KeesDijk
0

Je ne vois pas beaucoup de différence entre définir une valeur de retour à un moment donné et ensuite utiliser des conditions pour ignorer tout le code susceptible de le modifier, et returntout de suite, je choisis donc le retour direct; il n'y a donc pas de resultvariable.

Si vous avez une valeur intermédiaire qui peut ou non être modifiée par le code conditionnel, il ne s'agit pas d'un résultat (pour le moment), elle ne devrait donc certainement pas être nommée de la sorte.

Simon Richter
la source
0

Quand je travaillais en C ++ et je suppose que cela peut s’appliquer en Java, j’ai fait.

par exemple

int Width() const
{
    Requires(....);
    Requires(....);

    //calculation

    Ensures(...);
    Ensures(...);
    return Result;
}

Il s’agit d’une conception par contrat, le bloc d’assurance devant figurer à la fin de la méthode. Mais le retour doit être le dernier. La règle selon laquelle return était la seule chose qui pouvait suivre le blocage de la garantie.

ctrl-alt-delor
la source
0

Dans une fonction récursive, il est souvent efficace de porter le résultat pas à pas pour permettre une optimisation de l'appel final. Pour signaler à l'utilisateur qu'il n'a pas besoin de fournir un paramètre, il peut être raisonnable de nommer un paramètre "résultat":

def removeOccurence [A] (slice: Seq[A], original: Seq[A]) = {
  @scala.annotation.tailrec
  def remove (leftOriginal: Seq[A], result: Seq[A]) : Seq[A] =
    trimStart (slice, leftOriginal) match {
      case (h :: tail) => remove (tail, h +: result)
      case (Nil)       => result.reverse
    }
    remove (original, Nil)
}

Mais le plus souvent, j'utilise «carry» et «sofar», que j'ai vus à l'état sauvage, et qui portent l'idée un peu mieux, dans la plupart des cas.

Une deuxième raison est bien sûr, si votre sujet suggère le mot «résultat», par exemple si vous effectuez une évaluation arithmétique. Vous pouvez analyser la formule, remplacer les variables par des valeurs et calculer un résultat à la fin.

Une troisième raison a déjà été énoncée, mais j’ai un petit écart: vous écrivez une méthode qui effectue un travail, disons qu’elle évalue une forme de '' max ''.

def max = {
  val result = somethingElseToDo
  if (foo) result else default 
}

Au lieu d'appeler le résultat '' résultat '', nous pourrions l'appeler '' max '', mais dans certaines langues, vous pouvez omettre la parenthèse lorsque vous appelez une méthode. Ainsi, max serait un appel récursif à la méthode elle-même.

En général, je préférerais un nom qui indique le résultat. Mais si ce nom est déjà pris, peut-être par plus d’une variable, attribut ou méthode, car il existe un champ GUI, une représentation sous forme de chaîne, un numérique et un pour la base de données, l’utilisation d’un autre augmente le risque de confusion. Dans les méthodes courtes de 3 à 7 lignes, "résultat" ne devrait pas être un problème pour un nom.

Utilisateur inconnu
la source
0

En Object Pascal, ce n'est pas un choix. Vous devez attribuer une valeur à la Resultvariable quelque part dans le code de la fonction.

Exemple:

function AddIntegers( A,B: Integer): Integer;
begin
  Result := A + B; 
end; 

Donc, pour moi, il est assez naturel que la variable "Résultat" (ou "Retorno", telle que je l'orthographie en portugais pour éviter les conflits de noms avec les mots réservés de la langue) reçoive une valeur de retour.

Bien sûr, s’il s’agit d’une expression très simple dans un langage dérivé de C, je ne me soucierai pas de déclarer une variable de résultat - en renvoyant directement l’expression.

Fabricio Araujo
la source
0

ce n'est pas juste ce que vous nommez le résultat (je suis particulier à 'r'), mais aussi comment il est utilisé. Par exemple, si vous avez une variable de retour, chaque instruction de retour doit la renvoyer. ne pas avoir 'retour r;' à la fin, mais saupoudrez des choses comme 'return m * x + b; "dans toute la méthode / fonction. utilisez" r = m * x + b; retourne r; "à la place.

rbp
la source
-1

le résultat est bon. Je suis capable de comprendre le code au premier abord, donc le nom de la variable servait à cela.

java_mouse
la source