python - nomenclatura - pep8 pdf
¿Por qué Python pep-8 recomienda encarecidamente espacios sobre pestañas para indentación? (16)
Además de todas las otras razones ya nombradas (consistencia, nunca mezclar espacios y pestañas, etc.), creo que hay algunas razones más para que la convención de 4 espacios tenga en cuenta. Estos solo se aplican a Python (y tal vez a otros idiomas donde la sangría tiene significado). Las pestañas pueden ser más bonitas en otros idiomas, dependiendo de las preferencias individuales.
Si un editor no muestra pestañas (lo que sucede, dependiendo de la configuración, en bastantes), otro autor puede asumir que su código usa 4 espacios, b / c casi todo el código de Python que está disponible para el público lo hace; si ese mismo editor tiene un ancho de tabulación de 4, pueden ocurrir cosas desagradables; al menos, esa persona pobre perderá tiempo por un problema de sangría que habría sido muy fácil de evitar al apegarse a la convención. Entonces para mí, la razón número uno es evitar errores con consistencia.
Refirmando la pregunta de cuál es mejor, pestañas o espacios, uno debería preguntarse cuáles son las ventajas de las pestañas; He visto muchas publicaciones alabando pestañas, pero pocos argumentos convincentes para ellas; buenos editores como emacs, vi (m), kate, ... hacen una sangría adecuada dependiendo de la semántica de su código, incluso sin pestañas; los mismos editores se pueden configurar fácilmente para desencriptar en el retroceso, etc.
Algunas personas tienen preferencias muy fuertes cuando se trata de su libertad para decidir la apariencia / disposición del código; otros valoran la consistencia sobre esta libertad. Python reduce drásticamente esta libertad dictando que la sangría se usa para los bloques, etc. Esto se puede ver como un error o una característica, pero viene al elegir Python. Personalmente, me gusta esta consistencia: cuando empiezo a codificar en un nuevo proyecto, al menos el diseño es similar al que estoy acostumbrado, por lo que es bastante fácil de leer. Casi siempre.
El uso de espacios para sangría permite "trucos de diseño" que pueden facilitar la comprensión del código; algunos ejemplos de estos se enumeran en PEP8; p.ej.
foo = long_function_name(var_one, var_two, var_three, var_four) # the same for lists a_long_list = [1, 2, # ... 79] # or dictionaries a_dict = {"a_key": "a_value", "another_key": "another_value"}Por supuesto, lo anterior también se puede escribir muy bien como
foo = long_function_name( var_one, var_two, var_three, var_four) # the same for lists a_long_list = [ 1, 2, # ... 79] # or dictionaries a_dict = { "a_key": "a_value", "another_key": "another_value"}Sin embargo, este último toma más líneas de código y, a veces, se argumenta que hay menos líneas (b / c se obtiene más en una sola pantalla). Pero si le gusta la alineación, los espacios (preferiblemente asistidos por un buen editor) le otorgan, en cierto sentido, más libertad en Python que las pestañas. [Bueno, supongo que algunos editores te permiten hacer lo mismo con las pestañas;) - pero con espacios, todos lo hacen ...]
Volviendo al mismo argumento que todos los demás, PEP 8 dicta (bueno, recomienda encarecidamente) espacios. Si vienes a un proyecto que solo usa pestañas, por supuesto, no tienes muchas opciones. Pero debido al establecimiento de las convenciones de PEP 8, casi todos los programadores de Python están acostumbrados a este estilo. Esto hace que sea mucho más fácil encontrar un consenso sobre un estilo que sea aceptado por la mayoría de los programadores ... y si los individuos están de acuerdo en el estilo, puede ser muy difícil.
Las herramientas que ayudan a imponer el estilo suelen ser conscientes de PEP 8 sin esfuerzo adicional. Esa no es una buena razón, pero es bueno que las cosas funcionen de manera inmediata.
Veo en Stack Overflow y PEP 8 que la recomendación es usar espacios solo para sangría en programas de Python. Puedo entender la necesidad de una sangría consistente y he sentido ese dolor.
¿Hay alguna razón subyacente para que los espacios sean preferidos? Pensé que las pestañas eran mucho más fáciles de usar.
Bien, parece que todo el mundo está muy predispuesto hacia los espacios. Uso pestañas exclusivamente. Sé muy bien por qué.
Las pestañas son en realidad una invención genial, que vino después de los espacios. Le permite aplicar sangría sin presionar espacio millones de veces o usar una pestaña falsa (que produce espacios).
Realmente no entiendo por qué todo el mundo está discriminando el uso de pestañas. Es muy parecido a las personas mayores que discriminan a las personas más jóvenes por elegir una tecnología más nueva y eficiente y quejarse de que la marcación por pulsos funciona en todos los teléfonos , no solo en estos nuevos y elegantes. "La marcación de tono no funciona en todos los teléfonos, es por eso que está mal".
¿Tu editor no puede manejar las pestañas correctamente? Bueno, consigue un editor moderno . Podría ser el momento oportuno, ahora estamos en el siglo XXI y el tiempo en que un editor era una pieza de software complicada y de alta tecnología ya pasó. Ahora tenemos muchísimos editores para elegir, todos ellos compatibles con pestañas. Además, puede definir cuánto debe ser una pestaña, algo que no puede hacer con espacios. ¿No puedes ver las pestañas? ¿Qué es eso para una discusión? Bueno, ¡tampoco puedes ver espacios!
¿Puedo ser tan osado para sugerir conseguir un mejor editor? ¿Uno de estos de alta tecnología, que ya se lanzaron hace unos 10 años, muestra caracteres invisibles ? (sarcasmo apagado)
Usar espacios causa mucho más trabajo de eliminación y formateo. Es por eso que (y todas las demás personas que saben esto y están de acuerdo conmigo) usan pestañas para Python.
Mezcla de pestañas y espacios es un no-no y no hay argumento al respecto. Eso es un desastre y nunca puede funcionar.
Dado que python depende de la sangría para reconocer la estructura del programa, se requiere una forma clara de identificar la identación. Esta es la razón para elegir espacios o pestañas.
Sin embargo, Python también tiene una fuerte filosofía de tener solo una forma de hacer las cosas, por lo tanto, debería haber una recomendación oficial para una forma de hacer sangría.
Tanto los espacios como las pestañas presentan desafíos únicos que un editor puede manejar como sangrado. El manejo de las pestañas no es uniforme entre los editores o incluso la configuración del usuario. Como los espacios no son configurables, representan la opción más lógica ya que garantizan que el resultado se verá en todas partes de la misma manera.
El motivo de los espacios es que las pestañas son opcionales. Los espacios son el denominador común más bajo en la puntuación.
Cada editor de texto decente tiene un "reemplazo de pestañas con espacios" y muchas personas lo usan. Pero no siempre.
Mientras que algunos editores de texto pueden reemplazar una serie de espacios con una pestaña, esto es realmente raro.
Línea inferior . No puedes equivocarte con los espacios. Es posible que te equivoques con las pestañas. Por lo tanto, no use pestañas y reduzca el riesgo de errores.
El problema con las pestañas es que son invisibles y la gente nunca puede estar de acuerdo con el ancho de las pestañas. Cuando mezcle pestañas y espacios, y configure pestañas en otra cosa que no sea Python (que usa tabstops cada 8 espacios) verá el código en un diseño diferente del que Python lo ve. Y debido a que el diseño determina los bloques, verá una lógica diferente. Esto conduce a errores sutiles.
Si insistes en desafiar PEP 8 y usar pestañas, o peor, mezclando pestañas y espacios, al menos ejecuta python con el argumento ''-tt'', que crea una indentación incoherente (a veces una pestaña, a veces un espacio para la misma sangría) nivel) un error. Además, si es posible, configure su editor para que muestre las pestañas de manera diferente. Pero realmente, el mejor enfoque es no usar pestañas, punto.
El problema universal con las pestañas es que pueden representarse de manera diferente en diferentes entornos.
En un editor dado, una pestaña puede tener 8 espacios o puede ser 2.
En algunos editores, puedes controlar esto, mientras que en otros no puedes.
Otro problema con las pestañas es cómo se representan en la salida impresa. Creo que la mayoría de las impresoras interpretan una pestaña como 8 espacios.
Con espacios, no hay duda. Todo se alineará según lo previsto por el autor.
En la discusión entre Jim y Thomas Wouters en los comentarios.
El problema era ... dado que el ancho de las pestañas y espacios puede variar, y dado que los programadores no pueden acordar ninguno de los dos, ¿por qué las pestañas son las culpables?
Estoy de acuerdo con Jim en eso, las pestañas NO son malvadas en sí mismas. Pero hay un problema...
Con espacios puedo controlar cómo se ve "MI PROPIO CÓDIGO" en TODOS los editores del mundo. Si utilizo 4 espacios, no importa en qué editor abra mi código, tendrá la misma distancia desde el margen izquierdo. Con las pestañas estoy a merced de la configuración de ancho de pestañas para el editor, incluso para MI PROPIO CÓDIGO. Y no me gusta eso.
Por lo tanto, si bien es cierto que incluso los espacios no pueden garantizar la coherencia, al menos le permiten tener más control sobre el aspecto de su código PROPIO en todas partes, algo que las pestañas no pueden garantizar.
Creo que NO es la consistencia en los programadores que escriben el código, sino la consistencia en los editores que muestran ese código, que los espacios son más fáciles de lograr (e imponer).
La respuesta a la pregunta es: PEP-8 quiere hacer una recomendación y ha decidido que dado que los espacios son más populares, recomendará espacios en lugar de pestañas.
Notas sobre PEP-8
PEP-8 dice ''Use 4 espacios por nivel de sangría''.
Está claro que esta es la recomendación estándar.
''Para un código realmente antiguo que no quieres estropear, puedes continuar usando pestañas de 8 espacios.''
Está claro que hay ALGUNAS circunstancias en las que se pueden usar pestañas.
''Nunca mezcle pestañas y espacios.''
Esta es una clara prohibición de mezclar, creo que todos estamos de acuerdo en esto. Python puede detectar esto y a menudo se ahoga. Usar el argumento -tt hace que esto sea un error explícito.
''La forma más popular de sangrar Python es solo con espacios. La segunda forma más popular es solo con pestañas.
Esto indica claramente que ambos se usan. Solo para ser ultra claro: Aún así, nunca debes mezclar espacios y pestañas en el mismo archivo.
''Para los proyectos nuevos, los espacios solo se recomiendan encarecidamente en las pestañas''.
Esta es una recomendación clara, y una fuerte, pero no una prohibición de pestañas.
No puedo encontrar una buena respuesta a mi propia pregunta en PEP-8. Uso pestañas, que he usado históricamente en otros idiomas. Python acepta la fuente con el uso exclusivo de pestañas. Eso es lo suficientemente bueno para mí.
Pensé que podría trabajar en espacios. En mi editor, configuré un tipo de archivo para usar espacios exclusivamente y entonces inserta 4 espacios si presiono tab. Si presiono la pestaña demasiadas veces, ¡tengo que eliminar los espacios! Arrgh! ¡Cuatro veces más eliminaciones que pestañas! Mi editor no puede decir que estoy usando 4 espacios para las sangrías (aunque un editor de AN puede ser capaz de hacer esto) y obviamente insiste en eliminar los espacios de a uno por vez.
¿No se le podría decir a Python que considere las pestañas como n espacios cuando está leyendo las sangrías? Si pudiéramos aceptar 4 espacios por sangrado y 4 espacios por ficha y permitir que Python lo acepte, entonces no habría problemas.
Deberíamos encontrar soluciones que beneficien a todos los problemas.
La respuesta fue dada allí mismo en el PEP [ed: este pasaje fue editado en 2013 ]. Yo cito:
La forma más popular de sangrar Python es solo con espacios.
¿Qué otra razón subyacente necesitas?
Para decirlo sin rodeos: Considere también el alcance del PEP como se establece en el primer párrafo:
Este documento proporciona convenciones de codificación para el código Python que comprende la biblioteca estándar en la distribución principal de Python.
La intención es hacer que todos los códigos que vayan en la distribución oficial de python sean formateados consistentemente (espero que podamos estar de acuerdo en que esto es universalmente una buena cosa ™).
Dado que la decisión entre espacios y pestañas para un programador individual es a) realmente una cuestión de gusto yb) se maneja fácilmente por medios técnicos (editores, scripts de conversión, etc.), hay una forma clara de finalizar todas las discusiones: elija uno .
Guido fue el elegido. Ni siquiera tuvo que dar una razón, pero aún lo hizo al referirse a datos empíricos.
Para todos los demás propósitos, puede tomar este PEP como recomendación, o puede ignorarlo: su elección, la de su equipo o la de los líderes de su equipo.
Pero si te puedo dar un consejo: no los mezcles ;-) [ed: Mezclar pestañas y espacios ya no es una opción.]
La ventaja más importante que puedo decir de espacios sobre pestañas es que muchos programadores y proyectos usan un número determinado de columnas para el código fuente, y si alguien comete un cambio con su tabstop configurado en 2 espacios y el proyecto usa 4 espacios como las pestañas de las líneas largas van a ser demasiado largas para la ventana del editor de otras personas. Estoy de acuerdo en que las pestañas son más fáciles de usar, pero creo que los espacios son más fáciles para la colaboración, lo cual es importante en un gran proyecto de código abierto como Python.
Los principales problemas con la sangría se producen al mezclar pestañas y espacios. Obviamente, esto no te dice cuál elegir, pero es una buena razón para recomendar uno, incluso si lo eliges arrojando una moneda.
Sin embargo, en mi humilde opinión hay algunas razones menores para favorecer espacios sobre pestañas:
Diferentes herramientas. A veces el código se muestra fuera del editor de un programador. P.ej. publicado en un grupo de noticias o foro. Por lo general, a los espacios les va mejor que a las pestañas: en todos los lugares los espacios se destrozarían, las pestañas también, pero no al revés.
Los programadores ven la fuente de manera diferente. Esto es profundamente subjetivo: es el principal beneficio de las pestañas, o una razón para evitarlas, dependiendo de qué lado estés. En el lado positivo, los desarrolladores pueden ver la fuente con su sangría preferida, por lo que un desarrollador que prefiera la sangría de dos espacios puede trabajar con un desarrollador de 8 espacios en la misma fuente y seguir viéndolo como lo desee. La desventaja es que esto tiene repercusiones: a algunas personas les gusta el 8-espacio porque les da una opinión muy visible de que están anidados demasiado profundamente; es posible que vean el código revisado por el 2-indenter envolviendo constantemente en su editor. Hacer que cada desarrollador vea el código de la misma manera conduce a una mayor consistencia en las longitudes de línea, y también a otros asuntos.
Indentación de línea continua. A veces quieres sangrar una línea para indicar que es portada desde la anterior. p.ej.
def foo(): x = some_function_with_lots_of_args(foo, bar, baz, xyzzy, blah)Si usa pestañas, no hay forma de alinear esto para personas que usan tabstops diferentes en su editor sin mezclar espacios y pestañas. Esto efectivamente mata el beneficio anterior.
Obviamente, sin embargo, este es un tema profundamente religioso, cuya programación está plagada de problemas. El problema más importante es que debemos elegir uno, incluso si ese no es el que usted prefiere. A veces pienso que la mayor ventaja de la indentación significativa es que al menos nos ahorramos flamewars de colocación de corsé.
También vale la pena leer this artículo de Jamie Zawinski sobre el tema.
Personalmente, no estoy de acuerdo con espacios sobre pestañas. Para mí, las pestañas son un mecanismo / carácter de diseño del documento, mientras que los espacios son para el contenido o la delineación entre los comandos en el caso del código.
Tengo que estar de acuerdo con los comentarios de Jim de que las pestañas no son realmente el problema, son las personas y la forma en que quieren mezclar pestañas y espacios.
Dicho esto, me obligué a usar espacios por el bien de la convención. Valoro la consistencia sobre las preferencias personales.
Puedes tener tu pastel y comértelo. Configure su editor para expandir pestañas en espacios automáticamente.
(Eso sería :set expandtab en Vim)
Siempre he usado pestañas en mi código. Dicho esto, recientemente encontré una razón para usar espacios: al desarrollar en mi tableta de internet Nokia N900, ahora tenía un teclado sin una tecla de tabulación. Esto me obligó a copiar y pegar pestañas o volver a escribir mi código con espacios. Me he encontrado con el mismo problema con otros teléfonos. Por supuesto, este no es un uso estándar de Python, sino algo a tener en cuenta.
Tenga en cuenta que el uso de pestañas confunde otro aspecto de PEP 8:
Limite todas las líneas a un máximo de 79 caracteres.
Digamos, hipotéticamente, que usa un ancho de tabulación de 2 y uso un ancho de tabulación de 8. Escribe todo su código para que las líneas más largas alcancen 79 caracteres, y luego empiezo a trabajar en su archivo. Ahora tengo un código difícil de leer porque (como dice el PEP):
El ajuste predeterminado en la mayoría de las herramientas interrumpe la estructura visual del código
Si todos usamos 4 espacios, SIEMPRE es el mismo. Cualquier persona cuyo editor pueda soportar un ancho de 80 caracteres puede leer cómodamente el código. Nota: El límite de 80 caracteres es una guerra santa en sí misma, así que no comencemos eso aquí.
Cualquier editor no sucky debe tener una opción para usar espacios como si fueran pestañas (tanto insertar como eliminar), por lo que realmente no debería ser un argumento válido.
this :
Cuando [las personas están] leyendo el código, y cuando terminan de escribir el nuevo código, les importa cuántas columnas de pantalla el código tiende a sangrar cuando se abre un nuevo ámbito (o sexpr, o lo que sea) ...
... Mi opinión es que la mejor manera de resolver los problemas técnicos es ordenar que el carácter ASCII # 9 TAB nunca aparezca en los archivos del disco: programe su editor para expandir las TAB a un número adecuado de espacios antes de escribir las líneas en el disco. ..
... Esto supone que nunca se usan pestañas en lugares donde son realmente significativas, como en las constantes de cadenas o caracteres, pero nunca hago eso: cuando importa que sea una pestaña, siempre uso ''/ t'' en su lugar.