C'est pas complètement débile d'utiliser une convention pour aider à la lecture (ou à l'auto-complétion !) dans beaucoup de cas. J'ai vu pas mal de gens utiliser des préfixes du genre m_ pour une méthode d'instance, s_ pour une méthode de classe, _ pour un membre privé (ou protégé), etc.
Concernant les types dans un langage faiblement ET dynamiquement typé, je trouve au contraire que c'est loin d'être con, s'il y a potentiellement une ambiguïté sur la façon dont on compte se servir de la valeur :
my@valeurs=get_valeurs();# Je sais, c'est pas très idiomatique, mais j'fais c'que j'veux !@#$my$distribution=0;formy$i(@valeurs){$distribution+=$i;}# Pour le moment, $distribution est un int$distribution/=@valeurs;# PAF! $distribution devient float ou double!$distribution=int($distribution);# troncature, et $distribution redevient un int
Il y a de très bonnes raisons pour lesquelles une valeur devrait être flottante mais doit être représentée sous forme entière (parce que dans la vie réelle, il n'existe pas de version fractionnaire de la quantité modélisée par exemple). Le principe est évidemment d'appliquer les règles de préfixage avec parcimonie : une variable de compteur de boucle n'a pas besoin d'être préfixée, puisque généralement « allouée » au début de la boucle, puis mise à la poubelle à la fin : son contexte est clair et non-ambigu. Mais lorsqu'on parle de variables qu'on passe en paramètre à des fonctions, etc., préfixer les noms de variables peut être utile pour lever les ambiguïtés.
[^] # Re: Pascal...
Posté par lasher . En réponse au journal Python comme premier langage de programmation ?. Évalué à 2.
C'est pas complètement débile d'utiliser une convention pour aider à la lecture (ou à l'auto-complétion !) dans beaucoup de cas. J'ai vu pas mal de gens utiliser des préfixes du genre
m_pour une méthode d'instance,s_pour une méthode de classe,_pour un membre privé (ou protégé), etc.Concernant les types dans un langage faiblement ET dynamiquement typé, je trouve au contraire que c'est loin d'être con, s'il y a potentiellement une ambiguïté sur la façon dont on compte se servir de la valeur :
Il y a de très bonnes raisons pour lesquelles une valeur devrait être flottante mais doit être représentée sous forme entière (parce que dans la vie réelle, il n'existe pas de version fractionnaire de la quantité modélisée par exemple). Le principe est évidemment d'appliquer les règles de préfixage avec parcimonie : une variable de compteur de boucle n'a pas besoin d'être préfixée, puisque généralement « allouée » au début de la boucle, puis mise à la poubelle à la fin : son contexte est clair et non-ambigu. Mais lorsqu'on parle de variables qu'on passe en paramètre à des fonctions, etc., préfixer les noms de variables peut être utile pour lever les ambiguïtés.