En provenance de C#, la convention d'appellation des noms de variables et de méthodes est généralement en camelCase ou en PascalCase :
// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()En Python, j'ai vu ce qui précède, mais j'ai aussi vu l'utilisation de caractères de soulignement :
# python example
this_is_my_variable = 'a'
def this_is_my_function():Existe-t-il un style de codage plus préférable et définitif pour Python ?
Voir Python PEP 8 : Noms de fonctions et de variables :
Les noms des fonctions doivent être minuscules, les mots étant séparés par des traits de soulignement si nécessaire pour améliorer la lisibilité.
Les noms de variables suivent la même convention que les noms de fonctions.
Cas mixte n'est autorisé que dans les contextes où c'est déjà le style qui prévaut (par ex. threading.py ), afin de conserver une compatibilité ascendante.
Qu'en est-il des noms d'arguments de fonctions (en particulier, pour les arguments de mots-clés) ? PEP 8 n'est pas explicite à leur sujet. Je suppose que les minuscules et les caractères de soulignement sont également utilisés. Ou est-ce que les minuscules sin Les caractères de soulignement sont préférables ?
Le seul problème de l'utilisation des caractères de soulignement est que vous ne pouvez pas sélectionner un nom de variable ou de fonction par un double-clic... vous devez sélectionner le texte manuellement. C'est légèrement gênant.
En Guide de style Python de Google a la convention suivante :
module_name,package_name,ClassName,method_name,ExceptionName,function_name,GLOBAL_CONSTANT_NAME,global_var_name,instance_var_name,function_parameter_name,local_var_name.
Un schéma de dénomination similaire doit être appliqué à un projet de CLASS_CONSTANT_NAME
A) J'adore les exemples - merci. b) Mélange peu attrayant de CamelCase et de tirets bas ? Mais : Étant nouveau dans Python et son modèle de données plus flexible, je parie qu'il y a un raisonnement solide derrière le guide de Google...
@MatthewCornell Le mélange n'est pas mauvais tant que l'on s'y tient. En fait, cela facilite la lisibilité si vous savez que les fonctions ont des caractères de soulignement et que les classes n'en ont pas.
@MatthewCornell Je ne pense pas que cela ait un rapport avec Python. Go applique en fait des normes arbitraires de beauté et échouera à compiler si vous n'adhérez pas, par exemple, à leur convention d'accolades. Essentiellement, c'est un coup de dé pour savoir si quelqu'un a vraiment réfléchi ou s'il aime vraiment la façon dont il fait les choses.
David Goodger (dans "Code Like a Pythonista") aquí ) décrit les recommandations du PEP 8 comme suit :
joined_lower pour les fonctions, les méthodes, attributs, variables
joined_lower o ALL_CAPS pour constantes
StudlyCaps pour les classes
camelCase seulement pour se conformer à conventions préexistantes
+1 exemples visuels. Bien que je n'ai pas vu où PEP8 suggère joined_lower para constantes seulement "toutes les lettres majuscules avec des caractères de soulignement pour séparer les mots". Curieux aussi de voir le nouveau enum fonction.
StudlyCaps for classes est une grande règle universelle pour les classes dans presque toutes les langues. Alors pourquoi certaines classes intégrées à python (telles que datetime.datetime ne suit pas cette convention ?
@PrahladYeri : Malheureusement, unittest.TestCase.assertEqual et ses amis ne suivent pas non plus la convention snake_case. La vérité est que certaines parties de la bibliothèque standard de Python ont été développées avant que les conventions ne se soient solidifiées, et nous sommes maintenant coincés avec elles.
Comme mentionné, PEP 8 dit d'utiliser lower_case_with_underscores pour les variables, les méthodes et les fonctions.
Je préfère utiliser lower_case_with_underscores pour les variables et mixedCase pour les méthodes et les fonctions rend le code plus explicite et plus lisible. Ainsi, en suivant le Zen de Python "L'explicite est meilleur que l'implicite" et "La lisibilité compte".
+1 Je permute ces deux-là (j'utilise mixedCase pour les variables), mais le fait que tout soit plus distinct comme ça aide à rendre immédiatement évident ce à quoi on a affaire, surtout depuis que l'on peut passer des fonctions.
Bien que la "lisibilité" soit très subjective. Je trouve les méthodes avec un trait de soulignement plus lisibles.
Il y a PEP 8 Comme le montrent d'autres réponses, le PEP 8 n'est qu'un guide de style pour la bibliothèque standard, et il n'est pris comme parole d'évangile que dans ce guide. L'une des déviations les plus fréquentes de PEP 8 pour d'autres parties du code est le nommage des variables, en particulier pour les méthodes. Il n'y a pas de style prédominant unique, bien que, compte tenu du volume de code qui utilise la casse mixte, si l'on devait faire un recensement strict, on aboutirait probablement à une version de PEP 8 avec la casse mixte. Il n'y a guère d'autre déviation de PEP 8 qui soit aussi courante.
C'était peut-être vrai en 2008 lorsque la question a été posée, mais aujourd'hui, presque toutes les grandes bibliothèques utilisent les conventions de dénomination PEP 8.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
