Comment savoir si une variable a été définie à un endroit particulier du code au moment de l'exécution ? Ce n'est pas toujours évident car (1) la variable peut être définie de manière conditionnelle, et (2) la variable peut être supprimée de manière conditionnelle. Je cherche quelque chose comme defined()
en Perl ou isset()
en PHP ou defined?
en Ruby.
if condition:
a = 42
# is "a" defined here?
if other_condition:
del a
# is "a" defined here?
12 votes
Duplicata : stackoverflow.com/questions/843277/ , stackoverflow.com/questions/750298/ ,
89 votes
S'il vous plaît, s'il vous plaît, s'il vous plaît, ne définissez pas une variable de manière "conditionnelle". C'est juste une conception épouvantable, horrible. Toujours, toujours, toujours, toujours prévoir tous les chemins logiques. S'il vous plaît, ne continuez pas à faire cela.
2 votes
+1 à la réponse de S.Lott. Le fait qu'il existe un moyen de le faire ne signifie pas que vous devez l'utiliser dans un nouveau projet.
10 votes
@S.Lott : Je ne suis pas d'accord. Quand j'utilise
import
pour "sourcer" un "fichier de configuration" (c'est-à-dire un fichier qui ne contient que des affectations), il se peut très bien qu'une variable n'y ait pas été définie. Etimport
est certainement moins cher/simple queConfigParser
Donc, pour moi, le pragmatisme l'emporte sur la beauté.17 votes
@STATUS_ACCESS_DENIED : C'est à cela que servent les valeurs par défaut. Définissez d'abord les valeurs par défaut. Ensuite, importez votre configuration. Maintenant, toutes les variables sont définies, soit comme valeurs par défaut, soit comme valeurs prioritaires dans le fichier de configuration. Vous pouvez facilement éviter de définir une variable de manière conditionnelle.
0 votes
@S.Lott : Qu'en est-il dans une méthode de mémorisation ? Vous pouvez retourner ou mettre conditionnellement. C'est un standard dans Ruby, cette façon de penser est la raison pour laquelle je suis ici.
1 votes
Question stupide, je sais que je réfléchis trop... Par "paramétrer une variable de manière conditionnelle", voulez-vous dire que la existence d'une variable ne doit pas être basée sur une condition ?
1 votes
@dangel, oui. Vous pouvez penser "cette variable va jamais être référencée si
not condition
" Cependant, il a été démontré à maintes reprises (par expérience personnelle, du moins) que les programmeurs sont imparfaits et que les flux logiques peuvent en fait être différents des attentes. C'est particulièrement vrai pour le développement en spirale. où les hypothèses changent et où tout le code n'est pas audité/réfactorisé. Il ne coûte "presque rien" de définir la variable, indépendamment de la nature de l'opération.condition
même si elle n'est utilisée que lorsquecondition
est atteint.1 votes
@0xC0000022L La machinerie d'importation est lourde. Et elle n'est pas destinée à être utilisée pour des "fichiers de configuration". Si c'est la seule chose que vous voulez, vous feriez mieux d'utiliser
exec
oeval
. Cependant, cela serait très peu sûr à bien des égards, donc je pense que cela vaut la peine d'avoir un simple analyseur syntaxique. Quoi qu'il en soit, l'équivalent le plus proche d'unisset()
seraithasattr()
. On pourrait également utiliserglobals().get()
qui est capable de renvoyer un défaut.