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

Procedentes de un fondo de C #, la convención de nomenclatura para las variables y los nombres de los métodos suelen ser CamelCase o Pascal Case:

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

En Python, he visto lo anterior, pero también he visto guiones bajos utilizados:

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

¿Existe un estilo de encoding definitivo más preferible para Python?

Ver Python PEP 8 .

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

mixedCase está permitido solo en contextos donde ese ya es el estilo prevaleciente

Variables …

Utilice las reglas de nomenclatura de funciones: minúsculas con palabras separadas por guiones bajos según sea necesario para mejorar la legibilidad.

Personalmente, me desvío de esto porque también prefiero mixedCase en lugar de lower_case para mis propios proyectos.

Google Python Style Guide tiene la siguiente convención:

nombre_módulo, nombre de paquete, nombre de clase, nombre de método, nombre de excepción, nombre de función, NOMBRE_CONSTANTE GLOBAL, nombre_var_venta global, nombre_var de instancia, nombre_parámetro de función, nombre_variable local

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_lower o ALL_CAPS para 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 complicadas, por lo que nunca obtendremos esto completamente consistente

Tenga en cuenta que esto se refiere sólo a la biblioteca estándar de Python. Si no logran que sea tan consistente, entonces casi no hay esperanza de tener una convención generalmente aceptada para todo el código Python, ¿verdad?

De eso, y de la discusión aquí, deduciría que no es un pecado horrible si uno sigue utilizando, por ejemplo, las convenciones de nomenclatura (claras y bien establecidas) de Java o C # para las variables y funciones al cruzar a Python. Por supuesto, teniendo en cuenta que es mejor cumplir con el estilo que prevalece para un código base / proyecto / equipo. Como lo señala la Guía de estilo de Python, la consistencia interna es lo más importante.

Siéntete 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 evangelio en ella. 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 hay un estilo único predominante, aunque considerando el volumen de código que usa mixedCase, si uno hiciera un censo estricto, probablemente terminaría con una versión de PEP 8 con mixedCase. Hay poca otra desviación de la PEP 8 que es tan común.

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

Prefiero usar lower_case_with_underscores para variables y mixedCase para 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 “cuenta de legibilidad”

Personalmente trato de usar CamelCase para clases, métodos y funciones mixedCase. Las variables suelen estar subrayadas por separado (cuando puedo recordar). De esta manera puedo decir de un vistazo qué es exactamente lo que estoy llamando, en lugar de que todo se vea igual.

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

Simplemente me gusta más CamelCase ya que encaja mejor con la forma en que se nombran las clases. Parece más lógico tener SomeClass.doSomething() que SomeClass.do_something() . Si mira a su alrededor en el índice del módulo global en Python, encontrará ambos, lo cual se debe al hecho de que es una colección de bibliotecas de diversas fonts que creció en el tiempo extra y no algo que fue desarrollado por una compañía como Sun con estrictas reglas de encoding. . Yo diría que la conclusión es: usa lo que más te guste, es solo una cuestión de gusto personal.

más allá de lo que @JohnTESlade ha respondido. La guía de estilo python de Google tiene algunas recomendaciones bastante bonitas,

Nombres a evitar

  • Nombres de un solo carácter excepto contadores o iteradores.
  • Guiones (-) en cualquier paquete / nombre de módulo
  • \__double_leading_and_trailing_underscore__ names (reservados por Python)

Convenio de denominación

  • “Interno” significa interno a un módulo o protegido o privado dentro de una clase.
  • El prefijo de un solo guión bajo (_) tiene algún soporte para proteger las variables y funciones del módulo (no incluidas con importación * desde). Anteponer un doble guión bajo (__) a una variable o método de instancia sirve efectivamente para hacer que la variable o el método sean privados para su clase (utilizando la denominación de nombres).
  • 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.
  • Use CapWords para nombres de clase, pero lower_with_under.py para nombres de módulos. Aunque hay muchos módulos existentes llamados CapWords.py , ahora esto no se CapWords.py porque es confuso cuando el módulo recibe el nombre de una clase. (“espere, ¿escribí import StringIO o from StringIO import StringIO ?”)

Pautas derivadas de las recomendaciones de Guido introduzca la descripción de la imagen aquí

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 las lenguas modernas usan (o deberían usar) serpiente donde sea que puedan.

El estilo de encoding suele ser parte de los estándares internos de política / convención 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.

Normalmente, uno sigue las convenciones utilizadas en la biblioteca estándar del idioma.