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?
Respuestas:
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.
findMeAClasses quizás más feo que find_me_a_class.
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
property... tal vez es una cuestión de lo que el artículo pretende ser, en lugar de lo que realmente es
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
joined_lowerpara las constantes , sólo "con todas las letras mayúsculas subrayado que separa las palabras". Curioso también sobre la nueva función de enumeración .
StudlyCaps for classesEs una gran regla universal para las clases en casi todos los idiomas. Entonces, ¿por qué hay algunas clases incorporadas en Python (como las datetime.datetimeque no siguen esta convención?)
unittest.TestCase.assertEqualy los amigos tampoco siguen la convención snake_case. La verdad es que partes de la biblioteca estándar de Python se desarrollaron antes de que las convenciones se hubieran solidificado, y ahora estamos atrapados en ellas.
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
\__double_leading_and_trailing_underscore__ names (reservado por Python)Convenio de denominación
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.
make_xpath_predicate, make_xpath_expr, make_html_header,make_html_footer
SomeClass.doSomething()(los métodos estáticos son generalmente raros) generalmente llamaan_instance.do_something()
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.
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!
library_function(my_arg)).