¿Cuál es la convención de nomenclatura en Python para nombres de variables y funciones?

Viniendo de un fondo de C #, la convención de nomenclatura para variables y nombres de métodos suele ser camelCase o PascalCase:

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

En Python, he visto lo anterior pero también he visto que se usan guiones bajos:

# python example
this_is_my_variable = 'a'
def this_is_my_function():

¿Existe un estilo de codificación más preferible y definitivo para Python?

Ver Python PEP 8: Nombres de funciones y variables :

Los nombres de las funciones deben estar en minúsculas, con palabras separadas por guiones bajos según sea necesario para mejorar la legibilidad.

Los nombres de las variables siguen la misma convención que los nombres de las funciones.

mixedCase solo se permite en contextos donde ese es el estilo predominante (por ejemplo, threading.py ), para mantener la compatibilidad con versiones anteriores.

La Guía de estilo de Google Python tiene la siguiente convención:

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.

Se debe aplicar un esquema de nomenclatura similar a un CLASS_CONSTANT_NAME

David Goodger (en "Code Like a Pythonista" aquí ) describe las recomendaciones de PEP 8 de la siguiente manera:

• joined_lower para funciones, métodos, atributos, variables

• joined_lowero ALL_CAPSpara constantes

• StudlyCaps para clases

• camelCase solo para cumplir con las convenciones preexistentes

Como admite la Guía de estilo para Python Code ,

Las convenciones de nomenclatura de la biblioteca de Python son un poco desordenadas, por lo que nunca obtendremos esto completamente consistente

Tenga en cuenta que esto se refiere solo a la biblioteca estándar de Python . Si no pueden ser tan consistentes, entonces casi no hay muchas esperanzas de tener una convención generalmente adherida para todo el código Python, ¿verdad?

A partir de eso, y la discusión aquí, se lo deducir que es no un pecado horrible si se tiene usando, por ejemplo de Java o C # 's (clara y bien establecida) las convenciones de nomenclatura para las variables y funciones al cruzar a Python. Teniendo en cuenta, por supuesto, que es mejor cumplir con el estilo predominante para una base de código / proyecto / equipo. Como señala la Guía de estilo de Python, la consistencia interna es lo más importante.

^{Siéntase libre de despedirme como un hereje. :-) Al igual que el OP, no soy un "Pythonista", todavía no de todos modos.}

Hay PEP 8 , como muestran otras respuestas, pero PEP 8 es solo la guía de estilo para la biblioteca estándar, y solo se toma como un evangelio. Una de las desviaciones más frecuentes de PEP 8 para otras piezas de código es la denominación de variables, específicamente para los métodos. No existe un estilo único predominante, aunque teniendo en cuenta el volumen de código que utiliza mixedCase, si se hiciera un censo estricto, probablemente terminaría con una versión de PEP 8 con mixedCase. Hay poca otra desviación de PEP 8 que es tan común.

Como se mencionó, PEP 8 dice que se use lower_case_with_underscorespara variables, métodos y funciones.

Prefiero usar lower_case_with_underscorespara variables y mixedCasepara métodos y funciones hace que el código sea más explícito y legible. Por lo tanto, seguir el zen de Python "explícito es mejor que implícito" y "la legibilidad cuenta"

Además de lo que ha respondido @JohnTESlade. La guía de estilo de Python de Google tiene algunas recomendaciones bastante buenas,

Nombres a evitar

• nombres de caracteres únicos, excepto contadores o iteradores
• guiones (-) en cualquier nombre de paquete / módulo
• \__double_leading_and_trailing_underscore__ names (reservado por Python)

Convenio de denominación

• "Interno" significa interno a un módulo o protegido o privado dentro de una clase.
• Anteponer un solo guión bajo (_) tiene cierto soporte para proteger las variables y funciones del módulo (no incluido con import * from). Anteponer un doble guión bajo (__) a una variable o método de instancia efectivamente sirve para hacer que la variable o método sea privado para su clase (usando el cambio de nombre).
• Coloque clases relacionadas y funciones de nivel superior juntas en un módulo. A diferencia de Java, no es necesario limitarse a una clase por módulo.
• Se usa CapWordspara nombres de clase, pero lower_with_under.pypara nombres de módulos. Aunque hay muchos módulos existentes nombrados CapWords.py, esto ahora se desaconseja porque es confuso cuando el módulo recibe el nombre de una clase. ("espera - escribí import StringIOo from StringIO import StringIO?")

Pautas derivadas de las recomendaciones de Guido

La mayoría de las personas de Python prefieren los guiones bajos, pero incluso yo estoy usando Python desde hace más de 5 años en este momento, todavía no me gustan. Me parecen feos, pero tal vez eso es todo el Java en mi cabeza.

Simplemente como CamelCase mejor, ya que se ajusta mejor a la forma en que las clases se nombran, se siente más lógico tener SomeClass.doSomething()que SomeClass.do_something(). Si observa el índice de módulo global en Python, encontrará ambos, lo que se debe al hecho de que es una colección de bibliotecas de varias fuentes que crecieron horas extras y no algo que fue desarrollado por una compañía como Sun con estrictas reglas de codificación. . Yo diría que la conclusión es: usa lo que más te guste, es solo una cuestión de gusto personal.

Personalmente trato de usar CamelCase para clases, métodos y funciones de MixedCase. Las variables suelen estar separadas por un guión bajo (cuando puedo recordar). De esta manera puedo decir de un vistazo a qué estoy llamando exactamente, en lugar de que todo se vea igual.

Hay un documento sobre esto: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR Dice que snake_case es más legible que camelCase. Es por eso que los lenguajes modernos usan (o deberían usar) serpiente donde pueden.

El estilo de codificación suele ser parte de los estándares de política / convención internos de una organización, pero creo que, en general, el estilo all_lower_case_underscore_separator (también llamado snake_case) es más común en python.

Personalmente uso las convenciones de nomenclatura de Java cuando desarrollo en otros lenguajes de programación, ya que es coherente y fácil de seguir. ¡De esa manera no estoy luchando continuamente sobre qué convenciones usar, que no deberían ser la parte más difícil de mi proyecto!

Por lo general, uno sigue las convenciones utilizadas en la biblioteca estándar del lenguaje.