teclado tabulador tabulacion tab que programacion lenguaje espacio cual python coding-style indentation conventions

python - tabulacion - tabulador o espacio en programacion



Tabs versus espacios en la programación de Python (30)

Siempre he usado pestañas para la sangría cuando hago la programación de Python. Pero luego me topé con una pregunta aquí, en la que alguien señaló que la mayoría de los programadores de Python usan espacios en lugar de pestañas para minimizar los errores de editor a editor.

¿Cómo hace eso una diferencia? ¿Hay otras razones por las que uno usaría espacios en lugar de pestañas para Python? ¿O simplemente no es verdad?

¿Debo cambiar mi editor para insertar espacios en lugar de pestañas de inmediato o seguir adelante como solía hacerlo?

¿Cómo hace eso una diferencia?

Algunos editores están configurados de manera predeterminada para reemplazar un solo carácter de pestaña con un número establecido de caracteres de espacio, pero otros no lo están. Si todos usan espacios, esta diferencia en la configuración predeterminada del editor puede ser ignorada.

¿Hay otras razones por las que uno usaría espacios en lugar de pestañas para Python? ¿O simplemente no es verdad?

Sí, hay otras razones válidas como lo señalan muchas respuestas antes que yo. "PEP-8" lo dice, sin embargo, NO es una de esas razones. Esto se debe al mito de que el PEP-8 es el estándar de codificación para todos los códigos de Python, cuando en realidad es solo el estándar de codificación para el conjunto estándar de bibliotecas de Python. Algunos afirman que PEP-8 es ampliamente aceptado, y otros afirman que la mayoría de los programadores de Python usan espacios en lugar de pestañas. Me gustaría solicitar pruebas de estas afirmaciones, ya que el número de votos en este sitio muestra CLARAMENTE que las masas prefieren las pestañas. Me parece muy desafortunado que haya aceptado "PEP8 dice así" como la respuesta a su pregunta, cuando en realidad hay muchas otras respuestas que realmente explican las ventajas y desventajas relativas de los espacios y las pestañas.

¿Debo cambiar mi editor para insertar espacios en lugar de pestañas de inmediato o seguir adelante como solía hacerlo?

Depende, y la respuesta a esta pregunta final es donde pensé que podría agregar algo de valor a este hilo. En mi humilde opinión, independientemente del idioma que se use, el mejor estándar de codificación para usar depende de la situación en la que se encuentre:

  • Si comenzó a trabajar en una base de código ya existente: no sea difícil, siga el estándar de codificación existente
  • Si un equipo está comenzando en un nuevo proyecto desde cero: discuta, decida sobre un estándar de codificación al principio como equipo, y apéguese a él
  • Si va solo: haga lo que sea que lo haga sentir más feliz y productivo.

Entonces, ¿en qué situación caes?

Finalmente, para aclarar mi postura, para mis propios proyectos en solitario, uso las pestañas porque las pestañas tienen más sentido para mí y soy más productivo con las pestañas.

Además de todos los argumentos ya enumerados, este me parece bastante importante (de Mitos sobre la sangría ):

Además, las pestañas a menudo se destruyen o se convierten erróneamente durante las operaciones de copiar y pegar, o cuando se inserta una parte del código fuente en una página web u otro tipo de código de marcado.

Otro argumento (fuertemente específico para el entorno, sin embargo) contra las pestañas es que a veces faltan en los teclados de los teléfonos . Esto probablemente podría remediarse instalando un teclado alternativo, cuando sea posible.

Un argumento para las pestañas que nadie parecía haber mencionado aún es que 1 pestaña es 1 carácter (0x09, 1 byte en el archivo), mientras que 4 espacios son 4 caracteres (4 veces 0x20, 4 bytes en el archivo); por lo tanto, usar espacios da como resultado un desperdicio de espacio 4x.

Para concluir esta incoherente lista de argumentos, me gustaría citar la respuesta de Tim Peters en el Número 7012: Las pestañas son mejores que los espacios para la sangría :

El estándar de "solo espacios" de Python es para código distribuido. Años de experiencia temprana nos enseñaron sin lugar a dudas que las pestañas causaron problemas interminables para el código compartido (...)

Cada uno tiene diferentes preferencias sobre cuánto código debe ser sangrado. Digamos que usted comparte el código con alguien y él o ella tiene diferentes preferencias con respecto a la sangría. Si las sangrías están en pestañas, su amigo siempre puede cambiar el ancho de la pestaña en la configuración de su editor. Sin embargo, si las sangrías están en espacios, su amigo realmente tendrá que cambiar el código fuente si él o ella desea establecerlo según sus preferencias. Luego, cuando reciba los cambios de su amigo, puede decidir cambiarlo de nuevo según sus preferencias. En este caso, tendrá que lidiar con el tedio de cambiar los niveles de sangría de un lado a otro, o una persona debe adoptar las preferencias de la otra en el nivel de sangría. Si tanto usted como su amigo usan pestañas, el hecho de que tenga diferentes preferencias no es un problema, ya que cada uno puede ver diferentes niveles de sangría mientras el código permanece sin cambios. Por eso, en mi opinión, las pestañas son mejores que los espacios para la sangría en todos los lenguajes de programación.

Cansado de perseguir errores tipográficos de sangría (8 espacios? No, 7 oops 9 ...) Cambié mis fuentes a ''solo pestañas''.

1 pestaña == 1 nivel de sangría, punto final

El punto es: si desea mostrar la sangría como 4, 8 o pi / 12 de ancho de caracteres, simplemente cambie la configuración en su editor de texto, no se meta con el código.

(Personalmente, uso la pestaña de ancho de 4 caracteres ... pero algunos preferirían 3 u 8 espacios, o incluso usar fuentes de ancho variable).

Creo firmemente que sea cual sea la convención histórica, las pestañas son simplemente una mejor opción y deben reemplazar los espacios en cada línea futura de código Python escrita. Como echar a un tirano incompetente. Mi razón para esto es: la simplicidad como un valor central . ¿Usar dos o quizás cuatro caracteres para la tarea semántica de uno? No hay justificación más allá de la tradición, OMI.

Creo que hay una solución para tener ambos:

  1. Compatibilidad con PEP-8 y uso de espacios.
  2. Conveniencia de usar pestaña en lugar de 4 espacios

En Notepad ++, vaya a "preferencias" -> "configuración de la pestaña" y elija "Python" en la lista de la derecha. Luego, asegúrese de "tamaño de pestaña: 4", y marque la casilla "reemplazar [pestaña] por espacio". En este caso, simplemente puede usar la tecla de tabulación para sangrar, pero Notepad ++ realmente transforma eso en 4 espacios para usted.

Cuando estaba aprendiendo Python por primera vez, la idea de un espacio en blanco significativo me desanimó un poco, ya que la mayoría de los idiomas para usarlo son inflexibles. Dicho esto, me impresionó la capacidad de Python para comprender una variedad de estilos de sangrado. Al considerar qué estilo usar para un nuevo proyecto, creo que es importante tener en cuenta dos cosas.

  1. Primero, es importante entender cómo Python interpreta la sangría. Bryan Oakley mencionó la posibilidad de errores off-by-one al usar pestañas, pero esto no es posible con la configuración predeterminada del intérprete. Hay una mejor explicación de esto en Learning Python , de O''Reilly Media .

Básicamente, hay una variable (que se puede cambiar al incluir un comentario en la parte superior de un archivo de origen # tab-width:) que define el ancho de la pestaña. Cuando Python encuentra una pestaña, aumenta la distancia de sangría al siguiente múltiplo del ancho de la pestaña . Por lo tanto, si se ingresa un espacio seguido de una pestaña a la izquierda del archivo, el siguiente múltiplo del ancho de la pestaña es 8. Si se ingresa una pestaña por sí misma, sucede lo mismo.

De esta manera, es seguro, si su editor está configurado correctamente, para usar pestañas, e incluso para mezclar pestañas y espacios. Siempre y cuando establezca que las pestañas de su editor tengan el mismo ancho que la declaración de ancho de pestaña de Python (u 8 si está ausente). En general, es una mala idea utilizar un editor con un ancho de pestaña distinto de 8 espacios, a menos que especifique el ancho de pestaña en el archivo.

  1. Segundo, gran parte del diseño sintáctico de Python es fomentar la legibilidad del código y el estilo consistente entre los programadores en el mismo proyecto. Dicho esto, la pregunta es, para cualquier proyecto en particular, qué hará que el código sea más legible para las personas que trabajan en el proyecto . Ciertamente, es una buena idea mantener un estilo de sangría consistente, pero dependiendo de la plataforma y el editor utilizado por el proyecto, un estilo diferente puede tener sentido para diferentes proyectos. Si no hay una razón convincente para no cumplir con el PEP 8 , entonces tiene sentido hacerlo, porque se ajustará a lo que la gente espera.

Me he encontrado con proyectos que utilizan una combinación de pestañas y espacios con éxito. Básicamente, los espacios se utilizan para sangrar secciones pequeñas, donde el hecho de que se encuentre en una sección con sangría es relativamente poco importante; mientras que las pestañas se usan para llamar la atención del lector hacia una característica estructural grande. Por ejemplo, las clases comienzan con una pestaña, en la cual las verificaciones condicionales simples dentro de una función usan dos espacios.

Las pestañas también son útiles cuando se trata de grandes bloques de texto con sangría en múltiples niveles. Cuando abandona los niveles de sangrado de 3 a 4 niveles, es mucho más fácil alinearse con la pestaña adecuada que alinearse con el número adecuado de espacios. Si un proyecto no usa el estilo recomendado de PEP 8, probablemente sea mejor escribir una guía de estilo en un archivo en algún lugar para que el patrón de sangrado permanezca consistente y otras personas puedan leer explícitamente cómo configurar su editor para que coincida.

Además, Python 2.x tiene una opción -t para emitir advertencias sobre tabulaciones y espacios -tt y -tt para emitir un error. Esto solo se aplica a las pestañas y espacios mixtos dentro del mismo ámbito. Python 3 asume -tt y, por lo que he encontrado, no hay forma de deshabilitar esa comprobación.

El único inconveniente que experimento con el uso de espacios en lugar de pestañas es que no puedes eliminar fácilmente un nivel de sangría; tienes que eliminar cuatro espacios en lugar de una sola pestaña.

El error de editor a editor ocurre cuando tiene sangría mixta dentro de un archivo . Esto surge de la siguiente manera: un bloque de código se sangra con 4 espacios, y luego un nivel de sangría "en", se sangra con pestañas. Ahora los paganos que hicieron esto (mezclando tabulaciones y espacios) lo tenían así que sus pestañas también tienen 4 espacios, por lo que no ve problemas, y Python no ve problemas.

Ahora nuestra víctima llega más tarde, y tiene sus pestañas ajustadas a 8 espacios. Ahora nuestras víctimas piensan que el código parece estar en perfecto estado, y lo corrige eliminando un nivel de sangría , lo que ahora hace que el código parezca que todavía tiene 2 niveles de sangría, pero en realidad es un nivel . En este punto todo el infierno se desata.

La lección aquí es que nunca, nunca, mezclar tabulaciones y espacios. Si sigues con esto, es fácil reenviar tu código en espacios o pestañas, independientemente de lo que utilices personalmente. La mejor manera de asegurarse de no mezclar tabulaciones y espacios es ejecutar python siempre con -tt , lo que generará un error cuando las pestañas y los espacios se mezclen.

En cuanto a las pestañas y los espacios, personalmente utilizo las pestañas para separar la sangría de la apariencia: es mucho más fácil cambiar la apariencia del código cuando está sangrada con las pestañas que con los espacios. Sé que esto va en contra de lo que hace el 99% de los programadores de Python, pero esa es mi preferencia personal , y en cualquier caso es fácil convertir un archivo con pestañas en uno espaciado. Lo contrario no siempre es cierto, ya que accidentalmente puedes eliminar 4 espacios en cadenas, etc.

El problema con el uso de espacios en lugar de pestañas es que el tamaño del archivo se vuelve increíblemente grande. Por ejemplo, un archivo de 500 kb con sangría podría reducirse a 200 kb cuando se intercambian espacios por pestañas, por eso siempre uso tabulaciones.

Un tamaño de archivo más pequeño significa una carga, compilación, ejecución (en algunos casos) más rápida, etc.

Para mí, no tiene sentido usar espacios, pero si alguien usa un editor que tiene problemas con las pestañas, entonces pueden reemplazar "/ t" con "" o "" o lo que sea ...

Esto es PEP 8 partir de julio de 2017:

Parece que esta afirmación no deja espacio para ninguna otra opción.

Pero esto no es solo lo que nos dice PEP 8, unas líneas más tarde:

En lo anterior, la primera declaración expresa una preferencia por los espacios, y la segunda declaración reconoce la existencia de un código sangrado con pestañas y esta preferencia por algunos codificadores.

Entonces : PEP 8 es tabulador tolerante. Sin embargo, no tolera tabulaciones y espacios mezclados para la sangría, lo cual, dado que la sangría en sí es obligatoria, es comprensible.

Puede que valga la pena mencionar que el estilo de codificación Python de Google también sigue la regla de los 4 espacios.

Hay otros argumentos y justificaciones diferentes a favor de cualquiera de las pestañas o 4 espacios.

Si trabaja en una empresa que aplica PEP 8, o comparte su código regularmente con otras personas que siguen PEP 8, entonces el sentido común dicta 4 espacios. Estoy (estaba, tal vez) acostumbrado a las pestañas de C / C ++. Pero con un IDE configurado correctamente, la diferencia se vuelve mínima.

Hay un escenario en el que las pestañas simplemente no funcionan, a saber: dependiendo del estilo de codificación que esté utilizando, es posible que tenga que sangrar algunas líneas de código con la precisión de un espacio, es decir:

def foobar(): x = some_call(arg1, arg2)

En ese caso, usar solo pestañas no funcionará en absoluto; el uso de tabulaciones para la sangría principal y los espacios para la sangría secundaria funcionará, pero violará la dura regla de no mezclar las dos.

Este no será el caso, sin embargo, al utilizar un documento de convenciones / estilo de codificación que evite situaciones como en el ejemplo de código anterior.

La experiencia y el PEP-8 concluyen claramente que se deben evitar los espacios de mezcla y los TAB . Si desea mezclarlos, debe visualizar los espacios en blanco en el IDE, pero luego pierde la ventaja de la muesca de Python que hace que los ámbitos sean fácilmente visibles. La visualización de espacios en blanco en un IDE desordena la visualización.

Si se trata de TABs o espacios, entonces deben ser espacios por una simple razón: uno puede cambiar casi todos los IDE y editores de texto para reemplazar automáticamente las pestañas con espacios, pero lo contrario no es cierto.

Aunque existen IDE que pueden convertir automáticamente los espacios iniciales en una línea en pestañas, esto llevará eventualmente a tener una mezcla de pestañas y espacios. Considere declaraciones de varias líneas, como llamadas a funciones con muchos parámetros o cadenas de documentos. Mientras que el "ascii-art" también debe evitarse, puede suceder fácilmente por accidente que quede un solo espacio después de las pestañas principales.

Otras respuestas trajeron varios argumentos a favor de las pestañas:

  • Golpear TAB es más eficiente. Por supuesto, esto es cierto, pero todos los editores de texto permiten insertar inmediatamente el número deseado de espacios cuando se presiona una tecla de tabulación
  • El sangrado / Dedenting es más fácil cuando solo tiene que quitar una pestaña en lugar de 2/3/4/8 espacios. Es cierto, pero la mayoría de los editores de texto permiten hacer esto automáticamente de todos modos: la selección de bloque, la sangría / dedent son una funcionalidad básica de un editor de programación, como comentar / no comentar. Si un editor de texto no tiene esto implementado, al menos debería tener una funcionalidad de macro fácil de usar con la que se pueda lograr lo mismo.
  • A diferentes programadores les gustan los diferentes anchos de sangrado. Eso es cierto, y una clara ventaja de usar solo TAB s. El problema es la interacción con otros individuos y / o equipos. Para que esto funcione en el mundo real, todos tendrían que estar de acuerdo en usar solo TAB s. Como esto no ha sucedido, tampoco funciona. En un escenario del mundo real, hay un conjunto de directrices de codificación que un proyecto acuerda de todos modos, y el método de sangrado es ciertamente una de ellas, incluso en otros lenguajes de programación donde las implicaciones son "solo" a nivel visual.

Imho, el punto principal de la mayoría de las respuestas (si no todas) faltan aquí es la interacción entre equipos o individuos, especialmente en situaciones en las que la lista de participantes no se conoce al principio. Cuando el código cumple con el código, todos tienen que usar pestañas o todos tienen que usar espacios. No se puede mezclar sin eventualmente tener problemas de funcionalidad. La gente no es perfecta. Las herramientas no son perfectas. Es por eso que no deberíamos usar TAB en absoluto.

Ninguna respuesta está completa sin el enlace que Greg proporcionó en su respuesta ya: Python: Mitos sobre la sangría

La forma más "pythonic" es usar 4 espacios por nivel de sangría. El intérprete de Python sin embargo reconocerá espacios o pestañas. El único gottcha es que nunca debes mezclar espacios y pestañas , elige uno u otro. Dicho esto, la especificación recomienda espacios, la mayoría de los desarrolladores usan espacios, así que a menos que tenga una buena razón para no hacerlo, diría que vaya con espacios.

Mi principal razón para usar tabulaciones sobre espacios es la tecla de retroceso. Si estoy en una línea y quiero retroceder, eliminar una sangría en esa única línea, tengo que pulsar la tecla de retroceso 4x si fueran espacios; mientras que, solo necesito golpearlo una vez si es una pestaña.

Continuaré usando las pestañas porque, como se dijo antes, es más fácil convertir de pestañas a espacios, pero no al revés.

Estoy pensando que quiero escribir un programa simple que convierta código con espacios en código con pestañas, porque me encantan los espacios de odio. ¡Me llevan por la pared!

Oh! Y usar las teclas de flecha para navegar hacia la izquierda y hacia la derecha siempre es un dolor en el culo cuando hay espacios.

ACTUALIZACIÓN: Sublime Text 3 ahora elimina una pestaña suave completa con la tecla de retroceso; Sin embargo, la navegación con la tecla de flecha sigue siendo tediosa.

ACTUALIZACIÓN: ahora uso vscode y también escribí una extensión TabSanity para que resuelva el retroceso, la eliminación y la navegación con las teclas de flecha.

PUEDE mezclar tabulaciones y espacios ... PERO, una pestaña se considera que tiene la misma sangría que 8 espacios, por lo tanto, a menos que su editor esté configurado para considerar que una pestaña tenga 8 espacios, usted está buscando problemas al mezclarlos.

Por lo que puedo decir, aquí están los pros y los contras de las pestañas frente a los espacios.

Pros de las pestañas:

  • Se requieren menos pulsaciones de teclas para sangrar, desincrustar y atravesar la sangría. (Incluso si su IDE tiene algún tipo de espacio en la sangría, nunca será tan bueno como las pestañas).
  • Diferentes programadores pueden usar diferentes tamaños de visualización de pestañas como deseen.
  • Nunca puedes tener el cursor "dentro" de un carácter de sangría. Por ejemplo, digamos que está copiando algunas líneas, con pestañas puede hacer clic vagamente cerca del inicio de una línea para comenzar su selección y obtendrá todas las primeras pestañas. Con los espacios es probable que pierda el primer carácter de espacio a menos que golpee el objetivo pequeño entre él y el margen. De manera similar, para eliminar una sangría de una línea, la mayoría de los editores no manejan presionar la tecla de retroceso si el cursor está en medio de un carácter de sangría de cuatro espacios. Por lo general, se eliminará un espacio. Con pestañas funciona como se espera.
  • Coherencia con otros idiomas, por lo que no tiene que configurar su editor para su uso, por ejemplo, pestañas para C ++ / Java y espacios para Python.
  • Las sangrías incorrectas pueden ser más obvias (es decir, una pestaña adicional es mucho más grande que un espacio adicional).

Contras de las pestañas:

  • La mayoría de los programadores de Python usan espacios para que vayas en contra de la convención.
  • Usar espacios para alinear sentencias de varias líneas es más fácil que usar pestañas. Puedes usar tabulaciones para sangría, espacios para alineación, ¡pero parece un poco arriesgado en Python!

Hay algunas cuestiones que no son problemáticas y que son exageradas por algunas personas:

  1. Puede obtener espacios perdidos en la sangría con pestañas que complica las cosas: ¡prácticamente todos los IDE / editores admiten la visualización de espacios en blanco, y es casi tan probable que obtenga pestañas perdidas en las sangrías espaciales! No puedo ver que esto sea un error común de todos modos. Además, la mayoría de los errores de sangrado serán detectados por Python, y los buenos IDE deberían ser capaces de resaltar diferentes sangrados.

  2. No puedes alinear las cosas fácilmente con las pestañas: esto es cierto si vas por una alineación perfecta del personaje, pero PEP-8 recomienda esto, y Python no juega bien con declaraciones de varias líneas de todos modos.

  3. Las personas tienen diferentes configuraciones para el tamaño de visualización de las pestañas en sus editores, por lo que su código se verá diferente en diferentes lugares: Sí, esa es realmente una característica beneficiosa de las pestañas.

Comencé a usar espacios para ser coherente con otro código de Python, pero para ser sincero, es lo suficientemente frustrante que probablemente volveré a las pestañas. Mucho depende de las capacidades de su IDE, pero en mi experiencia, ninguna cantidad de soporte IDE para la sangría de espacio es tan buena como usar solo las pestañas.

Entonces, a menos que realmente no te guste ser inconsistente con la mayoría (¡probablemente no todo!) Del código de Python, usa las pestañas y activa la visualización de espacios en blanco y el resaltado de sangrado (si está disponible). La razón más importante para mí es la facilidad de selección y la reducción (bastante significativa de la OMI) en las pulsaciones de teclas. Algunas convenciones son estúpidas.

Porque PEP-8 nos dice que usemos espacios.

Recientemente encontré un artículo titulado Python: Myths about Indentation que discute esto y otras preguntas relacionadas. El artículo tiene buenas razones para recomendar el uso de espacios al escribir el código Python, pero ciertamente hay lugar para el desacuerdo.

Creo que es cierto que la mayoría de los programadores de Python solo usan espacios.

Reglas de las pestañas. El mismo argumento para los bucles anidados y desea que el bucle externo "vuelva" a 1 nivel. Sugerencia: si desea convertir el código Python antiguo y lleno de espacio en pestañas, use la utilidad TabOut disponible como ejecutable en http://www.textpad.com/add-ons/ .

Soy principalmente un programador de C ++, pero a veces mis proyectos incluyen pequeñas cantidades de Python. Yo uso pestañas para sangrar mi código C ++. Esto significa que tengo tres opciones aquí:

  1. Usa pestañas en C ++ y espacios en Python. Esto permite que mis archivos C ++ permanezcan como están y sigo la recomendación PEP-8, pero soy inconsistente dentro de mi proyecto.
  2. Cambiar mi código de C ++ para usar espacios. Esto permite que todos mis archivos dentro de mi proyecto sean consistentes, y sigo la recomendación PEP-8, pero me obliga a regresar y cambiar todos mis archivos C ++. Considero que esto es algo malo porque prefiero las pestañas.
  3. Usar pestañas en mi código C ++ y código Python. Esto hace que todo mi proyecto sea consistente y me permite usar mi estilo de sangría preferido: pestañas. El inconveniente es que no estoy siguiendo el estándar PEP-8.

Para mis proyectos, generalmente voy con la opción 3.

Use un editor que le permita insertar espacios hasta la tabulación cuando presiona la tecla TAB, en lugar de insertar un carácter / t. Y luego olvídalo.

Use un editor que muestre los caracteres de las fichas (todo el espacio en blanco, para el caso). Estás programando, no escribiendo un artículo.

Yo uso pestañas. No hay espacio para un error de un espacio en las pestañas (si puede verlas). El problema es que la gente usa editores diferentes, y la única cosa común en el mundo es: tab == sangría, como arriba. Algún tipo viene con la tecla de tabulación configurada en el número incorrecto de espacios o lo hace manualmente y desordena. TABs y usar un editor real. (Esto no es solo contrario al PEP, también se trata de C / C ++ y otros lenguajes agnósticos al espacio en blanco).

/ baja de la caja de jabón

Así habló el Señor: Harás sangría con cuatro espacios. Ni mas ni menos. Cuatro será el número de espacios que harás en la sangría, y el número de tu sangría será cuatro. Ocho no harás sangrado, ni tampoco sangrarás dos, excepto que luego procedes a cuatro. Las pestañas están bien sacadas. - Georg Brandl

Creo que uno de los principales beneficios de usar espacios es que elimina la variabilidad en la forma en que su código fuente se representa en la gran cantidad de herramientas externas que tienen que interactuar con la fuente más allá del editor de su elección y cualquier configuración en la que lo hayan configurado.

Como algunos ejemplos concretos consideran la representación de las cadenas de documentación de Python en una información sobre herramientas en Visual Studio Code , o en una herramienta de diferencias como Beyond Compare o WinMerge , WinMerge rendimiento o cobertura de código, etc. cómo se interpretan las pestañas y puede ser molesto y, a veces, desorientador encontrar cosas muy diferentes o alejadas de la pantalla entre los conjuntos de herramientas con los que puede meterse y salir.

En pocas palabras, usted define la alineación en la fuente en lugar de buscar una configuración uniforme para el conjunto de herramientas en su arsenal. Los espacios se interpretan estrictamente en una fuente monoespaciada para proporcionar una alineación confiable y consistente en todo el rango de herramientas debido a la definición de la fuente, no a la implementación / configuración de la representación de pestañas de un tercero.

Otro ángulo para esto es copiar el origen de las pestañas iniciales para que se ejecute en un terminal donde el carácter de la pestaña puede provocar la finalización involuntaria de la pestaña. Por ejemplo, si copia la siguiente fuente de Python (pestañas utilizadas como sangría),

cmd_create_db = ''''''CREATE TABLE test ( Col1 INTEGER, Col2 INTEGER, Col3 TEXT)''''''

puede ver algo como lo siguiente (visto en el terminal integrado de Visual Studio Code) ...

>>> cmd_create_db = ''''''CREATE TABLE test ( ... .DS_StoreCol1 INTEGER, ... .DS_StoreCol2 INTEGER, ... .DS_StoreCol3 TEXT)'''''' >>> cmd_create_db ''CREATE TABLE test (/n.DS_StoreCol1 INTEGER,/n.DS_StoreCol2 INTEGER,/n.DS_StoreCol3 TEXT)''

(Aparte: me pregunté si esta observación de consistencia en las herramientas es una marca de una mente discriminatoria de un desarrollador inteligente que busca ordenar el mundo que puede indicar una pista sobre la diferencia salarial encontrada en ).

Me encantan las pestañas, pero de alguna manera es incompatible con otra regla que me gusta: el límite de 80 columnas.

Si uno elige 4 tabulaciones de espacios e inserta 10 pestañas, entonces queda espacio para 40 caracteres para cumplir con el límite de 80 columnas. Si otro programador prefiere las pestañas de 8 espacios, la misma línea aparecerá con 120 caracteres de longitud y no aparecerá como una línea válida de 80 columnas.

Si desea definir un límite de 80 columnas, debe elegir una longitud para una pestaña. En este caso, tener x espacios o una pestaña de longitud x realmente no hace una diferencia.

Edición: tema relacionado: ¿ Mantener la longitud máxima de línea al usar pestañas en lugar de espacios?

Uso dos espacios de sangría y un editor (kwrite) que inserta espacios en lugar de pestañas cuando presiono la tecla tab.

Así que aquí estoy leyendo todas las respuestas y me pregunto cómo puedo cumplir con el PEP-8 sin la molestia de golpear mi botón de retroceso repetidamente solo para eliminar la sangría, y miro hacia abajo en mi teclado Logitech para juegos con todos sus elegantes botones macro y una luz. bombilla se enciende en mi cabeza Se abrió el software de logitech, se definieron un par de macros para los botones justo al lado del botón de pestaña y se resolvió el problema. Un botón agrega cuatro espacios, el otro retrocede cuatro veces. Increíble. Simplemente asombroso. Tan fácil de presionar los botones con mi meñique, también. Mira, mira esto: "" <- ¡cuatro espacios! ¡Con solo pulsar un botón! Si pudiera mostrarte los espacios en blanco, también lo haría. ¡Consiga un teclado Logitech G105 y todos sus problemas desaparecerán!

Estoy empezando, pero me resulta mucho más fácil usar pestañas que espacios, y no entiendo la advertencia de espacios de PEP-8 solamente. Sublime Text 2 hace un gran trabajo de visualización de pestañas con la línea de puntos, vertical, blanquecina y, si bien hay casos en los que mezclo uno o dos espacios para alinear elementos de una lista o diccionario, no he experimentado una situación en la que Ser lo perjudicial.