Rayo
Viniendo de un entorno de C#, la convención de nomenclatura para variables y 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 usa snake_case:
# python example
this_is_my_variable="a"
def this_is_my_function():
¿Existe un estilo de codificación definitivo más preferible para Python?
S. Lott
Ver Python PEP 8: Nombres de funciones y variables:
Los nombres de las funciones deben ser minúsculas, con palabras separadas por guiones bajos según sea necesario para mejorar la legibilidad.
Los nombres de variables siguen la misma convención que los nombres de funciones.
caso mixto está permitido solo en contextos donde ese ya es el estilo predominante (por ejemplo, enhebrar.py), para mantener la compatibilidad con versiones anteriores.
-
PEP = Propuesta de mejora de Python.
-Peter Mortensen
31 de julio de 2009 a las 21:18
-
El único problema con el uso de guiones bajos es que no puede seleccionar el nombre de una variable o función con un doble clic… tiene que seleccionar el texto manualmente. Es un poco molesto.
–Ricky Robinson
7 dic 2013 a las 14:13
-
Un caso para el estilo subrayado es que puede usar mejor palabras de una letra. Por ejemplo (un poco tonto),
findMeAClasses quizás más feo quefind_me_a_class.– Heltonbiker
28 de junio de 2014 a las 21:16
-
Encuentro que la convención de nombres de variables en minúsculas no es adecuada en la computación científica, donde uno a menudo se encuentra con constantes conocidas, tensores, etc. que se denotan con letras mayúsculas.
– andrésdr
17/10/2014 a las 20:00
-
@rr PEP8 es una “Guía de estilo” y se describe a sí mismo como una convención, NO como un estándar. También explica claramente las razones por las que no siempre se siguen esas “reglas”.
– El Tahan
13 de marzo de 2015 a las 8:28
Juan Slade
El 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
-
a) Me encantan los ejemplos – gracias. b) ¿Mezcla poco atractiva de CamelCase y guiones bajos? Pero: siendo nuevo en Python y su modelo de datos más flexible, apuesto a que hay un pensamiento sólido detrás de la guía de Google…
– Mateo Cornell
10 de septiembre de 2012 a las 14:29
-
La mezcla de @MatthewCornell no es mala siempre y cuando te apegues a ella. De hecho, facilita la legibilidad si sabe que las funciones tienen guiones bajos y las clases no.
– Pithikos
28 de septiembre de 2014 a las 9:53
-
@MatthewCornell No asumiría que tiene nada que ver con Python. Go en realidad impone estándares arbitrarios de belleza y no podrá compilar si no se adhiere, por ejemplo, a su convención de llaves. Esencialmente, es una tirada de dados en cuanto a si alguien realmente tuvo un pensamiento cuidadoso, o si realmente le encantó la forma en que hace las cosas.
– Tiro Parto
15 de junio de 2015 a las 21:14
-
¿Consideraría un atributo estático constante como GLOBAL_CONSTANT_NAME ? No es exactamente global, ya que está en el ámbito de la clase.
–James T.
23 de enero de 2018 a las 22:19
-
luego entra
property… tal vez es una cuestión de lo que pretende ser el elemento, en lugar de lo que realmente es– joel
8 oct 2019 a las 19:32
desmontado
David Goodger (en “Codifica como un Pythonista” aquí) describe las recomendaciones del PEP 8 de la siguiente manera:
-
joined_lowerpara funciones, métodos, atributos, variables -
joined_loweroALL_CAPSpara constantes -
StudlyCapspara clases -
camelCasesolo para ajustarse a convenciones preexistentes
-
+1 ejemplos visuales. Aunque no pude ver dónde sugiere PEP8
joined_lowerpara constantes, solo “todas las letras mayúsculas con guiones bajos que separan las palabras”. Curioso también acerca de la nueva función de enumeración.–Bob Stein
19 de enero de 2015 a las 13:11
-
StudlyCaps for classeses una gran regla universal para las clases en casi todos los idiomas. Entonces, ¿por qué algunas clases integradas de Python (comodatetime.datetimeno sigue esta convención?– Prahlada Yeri
12 de enero de 2017 a las 10:52
-
@PrahladYeri: Desafortunadamente,
unittest.TestCase.assertEqualy los amigos tampoco siguen la convención de los casos de serpientes. La verdad es que partes de la biblioteca estándar de Python se desarrollaron antes de que se solidificaran las convenciones, y ahora estamos atascados con ellas.– cargando
18 de marzo de 2017 a las 14:29
-
CamelCase es confuso porque algunas personas dicen que es “camelCase” (también conocido como “mixedCase”) y otras personas dicen que es “CamelCase” (también conocido como “StudlyCaps”). Por ejemplo, el PEP menciona “CamelCase” mientras que usted menciona “camelCase”.
– Pro Q
26 de junio de 2017 a las 14:55
-
su enlace aquí está muerto, tal vez debería ser reemplazado por algo como david.goodger.org/projects/pycon/2007/idiomatic
– Lobo
15 de octubre de 2019 a las 9:37
Jonik
como el Guía de estilo para código Python admite,
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 solo a Python biblioteca estándar. si no pueden conseguir eso consistente, entonces apenas hay muchas esperanzas de tener una convención de adhesión general para todo Código de Python, ¿hay?
De eso, y de la discusión aquí, deduciría que es no un pecado horrible si uno sigue usando, por ejemplo, las convenciones de nomenclatura de Java o C# (claras y bien establecidas) para variables y funciones al pasar a Python. Teniendo en cuenta, por supuesto, que es mejor atenerse al estilo predominante para una base de código/proyecto/equipo. Como señala la Guía de estilo de Python, consistencia interna lo que mas importa.
Siéntete libre de descartarme como un hereje. 🙂 Al igual que el OP, no soy un “Pythonista”, todavía no de todos modos.
Como se mencionó, PEP 8 dice usar 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. Siguiendo así la Zen de Python “explícito es mejor que implícito” y “La legibilidad cuenta”
-
+1 Cambio esos dos (uso mixedCase para variables), pero tener todo más distinto ayuda a que sea inmediatamente obvio con lo que estás tratando, especialmente porque puedes pasar funciones.
– Xiong Chiamiov
12 de julio de 2009 a las 17:51
-
Aunque la “legibilidad” es muy subjetiva. Encuentro métodos con guión bajo más legibles.
– Pithikos
30 de septiembre de 2014 a las 15:24
-
Su preferencia fue mi intuición inicial proveniente de muchos años de desarrollo en Java. Me gusta usar _ para variables, pero a simple vista, me parece un poco divertido para funciones y métodos.
–Michael Szczepaniak
13 de julio de 2016 a las 22:24
Tomás Wouters
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 allí. Una de las desviaciones más frecuentes de PEP 8 para otras piezas de código es la nomenclatura de variables, específicamente para métodos. No existe un único estilo 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 pocas otras desviaciones de PEP 8 que sean tan comunes.
-
+1 Cambio esos dos (uso mixedCase para variables), pero tener todo más distinto ayuda a que sea inmediatamente obvio con lo que estás tratando, especialmente porque puedes pasar funciones.
– Xiong Chiamiov
12 de julio de 2009 a las 17:51
-
Aunque la “legibilidad” es muy subjetiva. Encuentro métodos con guión bajo más legibles.
– Pithikos
30 de septiembre de 2014 a las 15:24
-
Su preferencia fue mi intuición inicial proveniente de muchos años de desarrollo en Java. Me gusta usar _ para variables, pero a simple vista, me parece un poco divertido para funciones y métodos.
–Michael Szczepaniak
13 de julio de 2016 a las 22:24
además de lo que ha respondido @JohnTESlade. Guía de estilo de python de Google tiene algunas recomendaciones bastante buenas,
Nombres a evitar
- nombres de un solo carácter 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 variables y funciones del módulo (no incluido con import * from). Anteponer un guión bajo doble (__) a una variable de instancia o método sirve efectivamente para hacer que la variable o método sea privado para su clase (mediante la manipulación de nombres).
- Coloque las clases relacionadas y las funciones de nivel superior juntas en un módulo. A diferencia de Java, no hay necesidad de limitarse a una clase por módulo.
- Usar
CapWordspara los nombres de las clases, perolower_with_under.pypara 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 StringIOofrom StringIO import StringIO?”)
Directrices derivadas de las Recomendaciones de Guido
