Quelle est la convention de dénomination en Python pour les noms de variable et de fonction?
-
03-07-2019 - |
Question
Venant d’un arrière-plan C #, la convention de dénomination des variables et des noms de méthodes est généralement soit CamelCase, soit Pascal Cas:
// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()
En Python, j'ai vu ce qui précède, mais j'ai aussi vu des traits de soulignement utilisés:
# python example
this_is_my_variable = 'a'
def this_is_my_function():
Existe-t-il un style de codage définitif plus préférable pour Python?
La solution
Voir Python PEP 8 .
Les noms de fonctions doivent être en minuscules, avec des mots séparés par des traits de soulignement nécessaire pour améliorer la lisibilité.
mixedCase n'est autorisé que dans des contextes où c'est déjà le dominant style
Variables ...
Utilisez les règles de nommage des fonctions: minuscule avec des mots séparés par souligne comme nécessaire pour améliorer lisibilité.
Personnellement, je m'en écarte car je préfère également mixedCase
à lower_case
pour mes propres projets.
Autres conseils
guide de style Google Python a la convention suivante:
nom_module, nom_package, NomClasse, nom_méthode, NomException, nom_fonction, GLOBAL_CONSTANT_NAME, nom_var global, nom_var_instance, nom_paramètre_fonction, nom_var_local
Un schéma de nommage similaire doit être appliqué à un CLASS_CONSTANT_NAME
David Goodger (dans "Code comme un Pythonista", ici ) décrit les recommandations du PEP 8 comme suit:
-
join_lower
pour les fonctions, méthodes, attributs, variables -
join_lower
ouALL_CAPS
pour constantes -
StudlyCaps
pour les classes -
camelCase
uniquement pour se conformer à conventions préexistantes
Comme le guide de style pour le code Python , admet,
Les conventions de nommage de Python bibliothèque sont un peu un gâchis, donc nous allons ne jamais obtenir cela complètement cohérent
Notez que cela ne concerne que la bibliothèque standard de Python. S'ils ne parviennent pas à obtenir une compatibilité cohérente, ils n'ont guère d'espoir d'une convention généralement acceptée pour tout le code Python, n'est-ce pas?
À partir de cela et de la discussion ici, je déduirais que ce n'est pas un horrible péché si on continue à utiliser, par exemple. Conventions de dénomination pour les variables et les fonctions de Java ou de C # (claires et bien établies) lors du passage à Python. En gardant à l'esprit, bien sûr, qu'il est préférable de respecter le style dominant pour une base de code / projet / équipe. Comme le souligne le Guide de style Python, la cohérence interne est primordiale.
N'hésitez pas à me considérer comme un hérétique. :-) Comme le PO, je ne suis pas un "pythoniste", pas encore de toute façon.
Il existe PEP 8 , comme le montrent d'autres réponses, mais PEP 8 n’est que le guide de style de la bibliothèque standard et n’y est considéré que comme un évangile. L'une des déviations les plus fréquentes de PEP 8 pour d'autres morceaux de code est la désignation 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 utilisant mixedCase, si l'on procédait à un recensement strict, on aboutirait probablement à une version de PEP 8 avec mixedCase. Il n’ya guère d’autre écart par rapport au PEP 8 qui soit aussi courant.
Comme mentionné, PEP 8 dit d’utiliser lower_case_with_underscores
pour les variables, méthodes et fonctions.
Je préfère utiliser lower_case_with_underscores
pour les variables et mixedCase
pour les méthodes et fonctions, pour rendre le code plus explicite et lisible. Ainsi, le Zen de Python " explicite est meilleur qu'implicite " et "La lisibilité compte"
Personnellement, j'essaie d'utiliser CamelCase pour les classes, les méthodes mixtes et les fonctions. Les variables sont généralement séparées par un trait de soulignement (quand je peux m'en souvenir). De cette façon, je peux dire en un coup d'œil ce que j'appelle exactement, au lieu que tout soit identique.
La plupart des gens python préfèrent les caractères de soulignement, mais même si je l’utilise depuis plus de 5 ans, je ne les aime toujours pas. Ils ont juste l'air moche pour moi, mais peut-être que c'est tout le Java dans ma tête.
J'aime tout simplement mieux CamelCase, car cela correspond mieux à la façon dont les classes sont nommées. Il est plus logique d'avoir SomeClass.doSomething ()
que SomeClass.do_something ()
. Si vous regardez dans l'index de module global en python, vous trouverez les deux, ce qui est dû au fait qu'il s'agit d'un ensemble de bibliothèques provenant de sources différentes qui ont connu une croissance du temps supplémentaire et non pas quelque chose qui a été développé par une société comme Sun avec des règles de codage strictes. . Je dirais que l’essentiel est: utilisez ce que vous préférez, c’est une question de goût personnel.
suite à ce que @JohnTESlade a répondu. Le guide de style de Google en python contient de jolies recommandations,
Noms à éviter
- noms de caractères uniques à l'exception des compteurs ou des itérateurs
- des tirets (-) dans n'importe quel package / nom de module
-
\ __ double_leading_and_trailing_underscore__ noms
(réservé par Python)
Convention de nommage
- " Interne " signifie interne à un module ou protégé ou privé dans une classe.
- La préfixe d'un simple trait de soulignement (_) prend en charge la protection des variables et des fonctions de module (non incluse dans import * de). Ajouter un double trait de soulignement (__) à une variable d'instance ou à une méthode sert effectivement à rendre la variable ou la méthode privée de sa classe (à l'aide de la gestion des noms).
- Placez les classes associées et les fonctions de niveau supérieur ensemble dans un module. Contrairement à Java, il n’est pas nécessaire de vous limiter à une classe par module.
- Utilisez
CapWords
pour les noms de classe, maislower_with_under.py
pour les noms de modules. Bien qu'il existe de nombreux modules existants nommésCapWords.py
, ceci est maintenant déconseillé car cela crée de la confusion lorsque le module est nommé après une classe. ("attendez - est-ce que j'ai écritimporter StringIO
ouà partir de StringIO importer StringIO
?")
Il existe un article à ce sujet: http: // www. .cs.kent.edu / ~ jmaletic / papers / ICPC2010-CamelCaseUnderScoreClouds.pdf
TL; DR Il est dit que snake_case est plus lisible que camelCase. C'est pourquoi les langues modernes utilisent (ou devraient utiliser) Snake partout où elles le peuvent.
Le style de codage fait généralement partie des normes de politique / convention internes d'une organisation, mais je pense qu'en général, le style all_lower_case_underscore_separator (également appelé snake_case) est plus courant en python.
Généralement, on respecte les conventions utilisées dans la bibliothèque standard du langage.