Parfois, j'ai essayé de trouver un bon nom de variable pendant quelques minutes, lorsque je réalise que cela ne vaut pas l'effort de cette petite boucle. Y a-t-il une situation où il serait justifié d'appeler une variable "temp"? P>
8 Réponses :
Bien sûr, si vous échangez par la valeur; ou si vous utilisez une notation variable telle que CALC pour le calcul, etc., vous devez utiliser Temp pour la température;) p> p >
+1 C'est le seul contre-cas que je pouvais penser. J'étais sur le point de poster une réponse affirmant pour échange code> ou
prev code> au lieu de
TEMP code> mais ... j'utilise
TEMP code> Dans ce cas (et c'est tout ce que je peux me rappeler), je vais donc jouer à l'avocat: P
En effet. Mais si vous faites cela dans une langue prenant en charge l'affectation parallèle ( a, b = b, a code>), vous devez être poignardé au visage (figuré).
@Jakub Hampl pas dans un certain nombre de langues "modernes", malheureusement.
C'est certainement un bon exemple, car "Temp" décrit la fonction de la variable. Je cherchais un cas où "Temp" ne veut pas dire quoi que ce soit.
Il y a toujours a ^ = b; b ^ = a; A ^ = B; code> et ensuite vous n'avez pas besoin
TEMP code>.
oui; Si la variable n'a pas de sens sémantique réelle, je dirais que dans la situation que vous décrivez, c'est parfaitement acceptable. P>
Venir avec un exemple est difficile; avez-vous une?
@IM: Chaque fois que je suis implémentée, disons, une équation complexe, je vais généralement le casser en plusieurs étapes sur plusieurs lignes. Ces résultats intermédiaires n'ont nécessairement aucune signification par eux-mêmes.
Je pense que c'est un mauvais exemple. Vous devriez toujours essayer de trouver une signification sensible de l'équation écartée et je n'ai jamais vu de cas où cela n'est pas possible. Cependant, si vous êtes en tant que programmeur, vous n'avez aucune idée de ce que l'algorithme fait alors, je suis totalement d'accord avec vous!
Chaque fois que vous avez besoin d'une variable intermédiaire, destiné à contenir temporairement des données lors de la manipulation de quelque chose d'autre, imo le nom Temp code> - il décrit clairement la fonction Variables. Échantillons: P>
char Temp[32]; sprintf(Temp, ...); RealVar += Temp;
int temp = a; a = b; b = temp;
Je préfère TMPFOO code> si la variable temporaire tenant un
foo code>. J'aime éliminer le besoin de variables temporaires inutiles encore plus.
Si c'est le nom le plus descriptif que vous puissiez penser. Parfois, vous pouvez l'étendre à "Temp << em> quelque chose em >>", auquel cas le "<< em> quelque chose em >>" est également un candidat à un nom. P>
Bien sûr. Lors de la modélisation météo: Cependant, si j'avais le malheur de la programmation dans une langue qui ne le supporterait pas et que c'était totalement off (par exemple temporaire), pourquoi pas: P> < Pré> xxx pré> p>
Vous devez utiliser la température ici pour éviter toute confusion.
Quelle confusion parlez-vous sur particulièrement? Je présume que vous seriez moins confus pourquoi votre code ne compile pas car vous avez Température code> dans un endroit et
Temeperature code> dans un autre?
Vous pouvez utiliser uniquement la première lettre de son sens pour un corps de fonction court, dans ce cas, "M" serait bien compris compte tenu de la fonction nom de fonction qui obtient / sets minutes a un nom de la description automatique, par exemple
var m = currentDate.Minute;
Oui, je pense qu'il y a un couple:
Non, ce n'est pas le cas.
IMHO: p> ou même p> est meilleur. p> p> p>
Nah, si vous allez utiliser un nom aussi sans signification que
TEMP code>, vous pouvez aussi bien utiliser
tmp code> ;-)
Si la variable n'est pas réellement temporaire, ou ce n'est pas une température, que non. À mon avis, bien sûr.
Duplicaté possible de Pourquoi utiliser un nom de variable "TEMP" considéré une mauvaise pratique?