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

879

Viniendo de un fondo de C #, la convención de nomenclatura para las variables y los nombres de métodos suelen ser camelCase o PascalCase:

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

En Python, he visto lo anterior, pero también he visto el uso de guiones bajos:

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

¿Existe un estilo de codificación definitivo más preferible para Python?

0
969

Consulte Python PEP 8: Nombres de funciones y variables :

Function names should be lowercase, with words separated by underscores as necessary to improve readability.

Variable names follow the same convention as function names.

mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.

22
  • 160
    PEP = Propuesta de mejora de Python. 31/07/09 a las 21:18
  • 11
    @RickyRobinson ¿Qué editor de código de muerte cerebral está usando, que no sabe que el subrayado continúa una palabra? Muchos gratuitos que lo hacen. Utilizo Notepad ++, si no hay un IDE disponible. Para eso, puede descargar una plantilla para la edición de Python. (Otros pueden recomendar descargas gratuitas aún más útiles). 16 de diciembre de 2013 a las 20:34
  • sesenta y cinco
    Un caso para el estilo subrayado es que puede usar mejor las palabras de una letra. Por ejemplo (un poco tonto), findMeAClasses quizás más feo que find_me_a_class. 28/06/2014 a las 21:16
  • 11
    Encuentro que la convención de los nombres de variables en minúsculas no es adecuada en la informática científica, donde a menudo uno se encuentra con constantes, tensores, etc. bien conocidos que se indican con letras mayúsculas. 17 oct 2014 a las 20:00
  • dieciséis
    @rr PEP8 es una "Guía de estilo" y se describe a sí misma como una convención, NO como una norma. También explica claramente las razones por las que no siempre se siguen esas "reglas". 13/03/15 a las 8:28
859

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

8
  • 46
    a) Me encantan los ejemplos, gracias. b) ¿Mezcla poco atractiva de CamelCase y guiones bajos? Pero: al ser 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 ... 10/09/12 a las 14:29
  • 26
    La mezcla de @MatthewCornell no está mal siempre y cuando te ciñas a ella. En realidad, facilita la legibilidad si sabe que las funciones tienen guiones bajos y las clases no. 28 de septiembre de 2014 a las 9:53
  • 2
    @MatthewCornell No asumiría que tiene algo que ver con Python. Go realmente aplica 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 si alguien realmente tuvo un pensamiento cuidadoso, o simplemente amaba la forma en que hacen las cosas. 15/06/15 a las 21:14
  • ¿Consideraría un atributo estático constante como GLOBAL_CONSTANT_NAME? No es exactamente global, ya que está en el alcance de la clase. 23/01/18 a las 22:19
  • luego entra property... tal vez sea una cuestión de lo que el artículo pretende ser, en lugar de lo que realmente es
    joel
    8/10/19 a las 19:32
265

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 ajustarse a convenciones preexistentes

6
  • 3
    +1 ejemplos visuales. Aunque no pude ver dónde sugiere PEP8 joined_lowerpara las constantes , solo "todas las letras mayúsculas con guiones bajos que separan las palabras". Curioso también por la nueva función de enumeración . 19/01/15 a las 13:11
  • 2
    StudlyCaps for classeses una gran regla universal para las clases en casi todos los idiomas. Entonces, ¿por qué hay algunas clases integradas de Python (como las datetime.datetimeque no siguen esta convención? 12 de enero de 2017 a las 10:52
  • 3
    @PrahladYeri: Desafortunadamente, unittest.TestCase.assertEqualy los amigos tampoco siguen la convención de snake_case. La verdad es que partes de la biblioteca estándar de Python se desarrollaron antes de que las convenciones se solidificaran, y ahora estamos atascados con ellas. 18 de marzo de 2017 a las 14:29
  • 3
    CamelCase es confuso porque algunas personas dicen que es "camelCase" (también conocido como "mixedCase") y algunas 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
    Wolf
    15 oct 2019 a las 9:37
49

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

The naming conventions of Python's library are a bit of a mess, so we'll never get this completely consistent

Tenga en cuenta que esto se refiere solo a la biblioteca estándar de Python . Si no pueden conseguir esa coherencia, entonces difícilmente hay muchas esperanzas de tener una convención generalmente adherida para todo el código de 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 respetar el estilo predominante de 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 tacharme de hereje. :-) Como el OP, no soy un "Pythonista", al menos no todavía.

34

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 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 solo 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 poca otra desviación de PEP 8 que sea tan común.

1
  • 13
    Esto puede haber sido cierto en el '08 cuando se respondió, pero hoy en día casi todas las bibliotecas principales usan convenciones de nomenclatura PEP 8. 28/10/15 a las 2:04
33

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

3
  • 3
    +1 Cambio esos dos (uso mixedCase para las variables), pero tener todo más distinto así ayuda a que sea inmediatamente obvio con qué estás lidiando, especialmente porque puedes pasar funciones. 12 jul 09 a las 17:51
  • 5
    Aunque la "legibilidad" es muy subjetiva. Encuentro los métodos con subrayado más legibles. 30 de septiembre de 2014 a las 15:24
  • Su preferencia fue mi intuición inicial proveniente de muchos años de desarrollo de Java. Me gusta usar _ para las variables, pero desde el punto de vista de los ojos, me parece un poco divertido para las funciones y los métodos. 13/07/2016 a las 22:24
26

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

Nombres para evitar

  • nombres de un solo carácter excepto para 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 las variables y funciones del módulo (no incluido con la importación * desde). Anteponer un guión bajo doble (__) a una variable de instancia o método sirve para hacer que la variable o el método sean privados de su clase (usando la modificación de nombres).
  • 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.
  • Úselo CapWordspara nombres de clases, 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 lleva el nombre de una clase. ("espera - ¿escribí yo import StringIOo from StringIO import StringIO?")

Directrices derivadas de las recomendaciones de Guido ingrese la descripción de la imagen aquí

23

La mayoría de las personas de Python prefieren guiones bajos, pero incluso yo estoy usando Python desde hace más de 5 años, todavía no me gustan. Simplemente 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. Se siente más lógico tener SomeClass.doSomething()que SomeClass.do_something(). Si miras a tu alrededor en el índice de módulo global en Python, encontrarás ambos, lo cual se debe al hecho de que es una colección de bibliotecas de varias fuentes que crecieron con el tiempo 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.

3
  • 12
    Vengo de un entorno de Java, y encuentro subrayados detallados y poco atractivos, y solo el último es opinión. Nombrar es, en algunos aspectos, un equilibrio entre legibilidad y brevedad. Unix va demasiado lejos, pero su en.wikipedia.org/wiki/Domain-specific_language es limitado. CamelCase es legible debido a las mayúsculas, pero no tiene caracteres adicionales. 2c 10/09/12 a las 14:29
  • 4
    Para mí, los guiones bajos son atractivos en funciones / métodos, ya que veo cada guión bajo como un separador de un espacio de nombres virtual (en mi cabeza). De esa manera puedo saber fácilmente cómo nombrar mis nuevas funciones / métodos: make_xpath_predicate, make_xpath_expr, make_html_header,make_html_footer 28 de septiembre de 2014 a las 9:59
  • 5
    No llamas (normalmente) SomeClass.doSomething()(los métodos estáticos son generalmente raros) normalmente llamasan_instance.do_something()
    Dave
    26 de septiembre de 2018 a las 23:40
19

Personalmente, trato de usar CamelCase para clases, métodos y funciones de MixedCase. Las variables suelen estar separadas por guiones bajos (cuando puedo recordar). De esta manera puedo decir de un vistazo qué estoy llamando exactamente, en lugar de que todo parezca igual.

4
  • 15
    El caso de camello comienza con una letra IIRC en minúscula como "camelCase". 3 de octubre de 2008 a las 11:51
  • 12
    Creo que crystalattice tenía razón; al menos, su uso es consistente con el uso en el PEP8 (CamelCase y mixedCase).
    Jarrett
    4/10/12 a las 19:34
  • 1
    @UnkwnTech El término para FirstLetterUpper a veces se llama PascalCase 3 de junio de 2019 a las 23:56
  • CamelCase o camelCase? sólo me preguntaba. 22/01/20 a las 19:29
15

Hay un artículo 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) serpientes siempre que pueden.

1
  • 12
    Curiosamente, también dice: "Los resultados de este estudio podrían no aplicarse necesariamente a los identificadores incrustados en el código fuente. Es muy posible que los identificadores en forma de camello actúen como un mejor elemento gestalt cuando se incrustan en construcciones de programación".
    rob3c
    2 oct 2016 a las 3:36
2

El estilo de codificación 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.

0

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!

1
  • 1
    Estoy algo de acuerdo. Si el lenguaje X es solo una pequeña parte del proyecto, el cambio de contexto de cómo formatear el texto puede ser una carga. El problema principal es que las bibliotecas tendrán llamadas en un estilo ( library_function(my_arg)).
    Lan
    22 abr.20 a las 1:51
0

Lenin ha dicho ... Yo también soy del mundo Java / C #. Y SQL también. Me escudriñé en un intento de encontrar ejemplos comprensibles a primera vista de construcciones complejas como list en el diccionario de listas donde todo es un objeto. En cuanto a mí, camelCase o sus variantes deberían convertirse en estándar para cualquier idioma. Los guiones bajos deben conservarse para las oraciones complejas.

-2

Por lo general, se siguen las convenciones utilizadas en la biblioteca estándar del idioma.