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

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

Pregunta

Viniendo de un fondo de C #, la convención de nomenclatura para variables y nombres de métodos generalmente son CamelCase o Pascal Case: 

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

En Python, he visto lo anterior pero también he visto subrayados en uso: 

# 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?

¿Fue útil?

Solución

Ver Python PEP 8 .

  

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

     

mixedCase está permitido solo en contextos   donde esa ya es la que prevalece   estilo

Variables ...

  

Use las reglas de nomenclatura de funciones:   minúsculas con palabras separadas por   subraya según sea necesario para mejorar   legibilidad.

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

Otros consejos

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

  

nombre_módulo, nombre_de_paquete, Nombre de clase, nombre_método, Nombre de excepción,   nombre_función, GLOBAL_CONSTANT_NAME, global_var_name,   nombre_var_instancia, nombre_parámetro_función, nombre_var_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:

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

  • join_lower o ALL_CAPS para constantes

  • StudlyCaps para clases

  • camelCase solo para cumplir con convenciones preexistentes

Como Guía de estilo para código Python admite,

  

Las convenciones de nomenclatura de Python   la biblioteca es un poco desordenada, así que   nunca consigas esto completamente consistente

Tenga en cuenta que esto se refiere solo a la biblioteca estándar de Python. Si no pueden obtener eso consistente, entonces casi no hay mucha esperanza de tener una convención generalmente adherida para el código Python all , ¿verdad?

A partir de eso, y de la discusión aquí, deduciría que no es un pecado horrible si uno sigue usando, p. Convenciones de nomenclatura de Java o C # (claras y bien establecidas) para variables y funciones al cruzar a Python. Teniendo en cuenta, por supuesto, que es mejor cumplir con el estilo prevaleciente 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éntete libre de despedirme como hereje. :-) Al igual que el OP, todavía no soy un "Pythonista", todavía no.

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 el nombre variable, 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 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 que hacen que el código sea más explícito y legible. Por lo tanto, seguir el Zen of Python " explícito es mejor que implícito " y "La legibilidad cuenta"

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.

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

Simplemente me gusta más CamelCase ya que encaja mejor con la forma en que se nombran las clases, 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.

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

Nombres a evitar

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

Convención de nomenclatura

  • " 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 las clases relacionadas y las 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 los nombres de clase, pero lower_with_under.py para los nombres de los módulos. Aunque hay muchos módulos existentes llamados CapWords.py , esto ahora se desaconseja porque es confuso cuando el módulo lleva el nombre de una clase. (" espera - ¿escribí import StringIO o desde StringIO import StringIO ? ")

Directrices derivadas de las Recomendaciones de Guido ingrese 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 los idiomas modernos usan (o deberían usar) serpiente donde puedan.

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.

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top