¿Cuál es la convención de nomenclatura en Python para nombres de variables y funciones?
-
03-07-2019 - |
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?
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, variablesjoin_lower
oALL_CAPS
para constantesStudlyCaps
para clasescamelCase
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, perolower_with_under.py
para los nombres de los módulos. Aunque hay muchos módulos existentes llamadosCapWords.py
, esto ahora se desaconseja porque es confuso cuando el módulo lleva el nombre de una clase. (" espera - ¿escribíimport StringIO
odesde StringIO import StringIO
? ")
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.