Quelle est la convention de dénomination en Python pour les noms de variable et de fonction?

StackOverflow https://stackoverflow.com/questions/159720

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?

Était-ce utile?

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

Le

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 ou ALL_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, mais lower_with_under.py pour les noms de modules. Bien qu'il existe de nombreux modules existants nommés CapWords.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 écrit importer StringIO ou à partir de StringIO importer StringIO ?")

Instructions dérivées des recommandations de Guido entrer la description de l'image ici

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.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top