Quelle est la convention de dénomination en Python pour les noms de variables et de fonctions?

Venant d'un arrière-plan C #, la convention de dénomination des variables et des noms de méthode est généralement camelCase ou PascalCase:

// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()

En Python, j'ai vu ce qui précède, mais j'ai également vu des soulignements 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?

Voir Python PEP 8: noms de fonction et de variable :

Les noms de fonction doivent être en minuscules, avec des mots séparés par des traits de soulignement si nécessaire pour améliorer la lisibilité.

Les noms de variable suivent la même convention que les noms de fonction.

mixedCase n'est autorisé que dans des contextes où c'est déjà le style dominant (par exemple threading.py ), pour conserver la compatibilité descendante.

Le guide de style Google Python 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 CLASS_CONSTANT_NAME

David Goodger (dans "Code Like a Pythonista" ici ) décrit les recommandations de PEP 8 comme suit:

• joined_lower pour les fonctions, méthodes, attributs, variables

• joined_lowerou ALL_CAPSpour des constantes

• StudlyCaps pour les cours

• camelCase uniquement pour se conformer aux conventions préexistantes

Comme le reconnaît le Guide de style pour le code Python ,

Les conventions de dénomination de la bibliothèque de Python sont un peu désordonnées, donc nous n'obtiendrons jamais cela complètement cohérent

Notez que cela se réfère uniquement à la bibliothèque standard de Python . S'ils ne peuvent pas obtenir cette cohérence, alors il n'y a guère d'espoir d'avoir une convention généralement respectée pour tout le code Python, n'est-ce pas?

De cela, et de la discussion ici, je déduirais que ce n'est pas un péché horrible si l'on continue à utiliser, par exemple, les conventions de nommage de Java ou de C # (claires et bien établies) pour les variables et les fonctions lors du passage à Python. Gardant à l'esprit, bien sûr, qu'il est préférable de respecter le style qui prévaut 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 rejeter comme hérétique. :-) Comme l'OP, je ne suis pas "Pythonista", pas encore de toute façon.}

Il y a PEP 8 , comme d'autres réponses le montrent, mais PEP 8 n'est que le guide de style pour la bibliothèque standard, et il n'est considéré que comme un évangile. L'un des écarts les plus fréquents de PEP 8 pour d'autres morceaux de code est la dénomination 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 mixedCase, si l'on devait faire un recensement strict, on se retrouverait probablement avec une version de PEP 8 avec mixedCase. Il y a peu d'autre déviation par rapport à PEP 8 qui est tout aussi courante.

Comme mentionné, PEP 8 dit d'utiliser lower_case_with_underscorespour les variables, les méthodes et les fonctions.

Je préfère utiliser lower_case_with_underscorespour les variables et mixedCasepour les méthodes et fonctions rend le code plus explicite et lisible. Ainsi, suivre le Zen de Python "explicite vaut mieux qu'implicite" et "Nombre de lisibilité"

suite à ce que @JohnTESlade a répondu. Guide de style python de Google contient des recommandations assez soignées,

Noms à éviter

• noms de caractère unique, sauf pour les compteurs ou les itérateurs
• tirets (-) dans n'importe quel nom de module / module
• \__double_leading_and_trailing_underscore__ names (réservé par Python)

Convention de dénomination

• "Interne" signifie interne à un module ou protégé ou privé au sein d'une classe.
• L'ajout d'un seul trait de soulignement (_) prend en charge la protection des variables et des fonctions du module (non inclus avec import * from). L'ajout d'un double trait de soulignement (__) à une variable ou une méthode d'instance permet en fait de rendre la variable ou la méthode privée à sa classe (en utilisant le changement de nom).
• Regroupez les classes associées et les fonctions de niveau supérieur dans un module. Contrairement à Java, il n'est pas nécessaire de vous limiter à une classe par module.
• À utiliser CapWordspour les noms de classe, mais lower_with_under.pypour les noms de module. Bien qu'il existe de nombreux modules existants nommés CapWords.py, cela est désormais déconseillé car cela prête à confusion lorsque le module porte le nom d'une classe. ("attends - ai-je écrit import StringIOou from StringIO import StringIO?")

Lignes directrices dérivées des recommandations de Guido

La plupart des gens python préfèrent les soulignés, mais même j'utilise python depuis plus de 5 ans en ce moment, je ne les aime toujours pas. Ils me semblent laids, mais c'est peut-être tout Java dans ma tête.

Je simplement comme CamelCase mieux , car il correspond mieux à la façon dont les classes sont nommées, il se sent plus logique d'avoir SomeClass.doSomething()que SomeClass.do_something(). Si vous regardez autour de l'index du module global en python, vous trouverez les deux, ce qui est dû au fait que c'est une collection de bibliothèques provenant de diverses sources qui ont augmenté au fil du temps et non quelque chose qui a été développé par une entreprise comme Sun avec des règles de codage strictes . Je dirais que l'essentiel est: utilisez ce que vous aimez mieux, c'est juste une question de goût personnel.

Personnellement, j'essaie d'utiliser CamelCase pour les classes, les méthodes et les fonctions mixedCase. Les variables sont généralement séparées par des traits de soulignement (si je me souviens bien). De cette façon, je peux dire en un coup d'œil ce que j'appelle exactement, plutôt que tout ce qui se ressemble.

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) serpent partout où elles le peuvent.

Le style de codage fait généralement partie des normes internes de politique / convention d'une organisation, mais je pense qu'en général, le style all_lower_case_underscore_separator (également appelé snake_case) est le plus courant en python.

J'utilise personnellement les conventions de dénomination de Java lors du développement dans d'autres langages de programmation car il est cohérent et facile à suivre. De cette façon, je ne me bats pas continuellement sur les conventions à utiliser qui ne devraient pas être la partie la plus difficile de mon projet!

En règle générale, on suit les conventions utilisées dans la bibliothèque standard du langage.