Tabulaciones versus espacios: ¿cuál es el carácter de sangría adecuado para todo, en cada situación, alguna vez? [cerrado]

Los estándares de codificación para el código alojado en drupal.org sugieren usar dos espacios para sangrar el código; otros sitios sugieren usar pestañas para sangrar el código.

¿Cuál es el carácter de sangría apropiado para todo y en cada situación? Por favor explique la respuesta que da.

Espacios

Una pestaña podría ser un número diferente de columnas dependiendo de su entorno, pero un espacio siempre es una columna.

En términos de cuántos espacios (o pestañas) constituyen sangría, es más importante ser coherente en todo el código que usar cualquier valor específico de tabulación.

Pestañas

Ahora, por supuesto, la consistencia importa más que cualquiera de los dos, y un buen IDE hace que las diferencias sean insignificantes. Dicho esto, el objetivo de este hilo es ser una guerra santa, así que:

Prefiero pestañas:

• Son un personaje específicamente destinado a la sangría
• Permiten a los desarrolladores con diferentes preferencias en tamaño de sangría cambiar cómo se ve el código sin cambiar el código (¡separación de datos y presentación para la proverbial victoria!)
• Es imposible sangrar algo con pestañas. Entonces, cuando copie código de un sitio web que usa 3 espacios en su archivo sangrado de 4 espacios, no tiene que lidiar con la desalineación.

Use pestañas para sangrar el inicio de la línea, una pestaña por nivel de sangría, y deje que todos elijan qué tan ancho quieren que sea.

Use espacios si está alineando caracteres dentro de una línea, para que siempre se alineen independientemente del tamaño de la pestaña.

Y encuentre y golpee a todos los primeros autores de software que dejaron que esta estupidez se convirtiera en un problema en primer lugar.
(En serio, ¿por qué esto es algo que se discute? ¡Luego me dirás que también quieres usar varios caracteres para los saltos de línea!)

Pestañas

• Permitir que los errores sean más notorios , es molesto micro administrar los espacios.
• son consistentes , solo se usan para sangrar, a menos que esté comentando mal.
• son personalizables , puede especificar en las opciones del editor qué tan anchos son.
• son más productivos , ¿por qué escribir 4 espacios cuando puedes presionar 1 pestaña?
• tomar menos tamaño que múltiples espacios.
• ocupa más espacio que un espacio.
• Tómese menos tiempo para pasar .
• tienden a funcionar mejor en IDEs.

Se deben usar espacios donde las pestañas son completamente inútiles.

Incluso para alinear parámetros y comentarios, las pestañas aún funcionan mejor .

Todos los argumentos para las pestañas son geniales en teoría. Pero...

En teoría, práctica y teoría son lo mismo. En la práctica, no lo son.

Sí, con pestañas puedes decidir tu nivel de sangría. Y sí, puede usar una combinación de pestañas y espacios para alinear cosas. Y en un mundo ideal sería

En realidad, no puede ver la diferencia entre espacios y pestañas, siempre parecen confundirse al mover el código, y ver el código en otro programa que tiene pestañas configuradas en 8 columnas es una molestia.

Yo solía usar pestañas. Luego comencé a trabajar como parte de un equipo y a compartir código. Rápidamente me convertí en un defensor de los espacios. Entonces, aunque puedo simpatizar con la utopía de las pestañas, no puedo imaginar no usar espacios.

Algunas opiniones relevantes que pueden ser de interés:

• Guido dice espacios
• Joel dice espacios
• Atwood dice espacios
• Zawinski dice espacios, más o menos

Pestañas para la victoria.

Yo absolutamente. odio. 4. espacios.

¿Por qué? Principalmente porque estoy cansado de navegar mi código con un teclado y tener que presionar constantemente left left left leftpara pasar por una sangría. Esto nació de las primeras versiones de Notepad ++ e incluso del bloc de notas simple de Windows donde no existía un botón de formato. Tuve tantos problemas cuando la gente solo usaba 3 cuando había usado 4 en todas partes, entre otras cosas.

La otra razón es que el carácter de tabulación existe específicamente para la sangría y solo se adoptó más tarde para la navegación. ¿Por qué estamos haciendo space space space spacecuando un simple tabfuncionaría? ¿Por qué los IDE tienen que lidiar con 2-5 códigos espaciados y formatear correctamente cuando una pestaña simple y una opción de preferencia funcionaría?

Lamentablemente soy la minoría.

Personalmente, me gusta usar pestañas en todo, ya que cada desarrollador puede controlar la cantidad de sangría por pestaña. De esa manera obtienes flexibilidad en la visualización.

Dicho esto, generalmente imito cualquier estilo de codificación en el archivo para comenzar (ya que paso mucho tiempo haciendo trabajos de mantenimiento).

No creo que exista una sangría adecuada (al menos no sin una guerra menor).

Personalmente me gustan cuatro espacios. Me permiten leer el código mucho más rápido y se ven iguales en todos los editores, incluso Vi.

Espacios, porque cuando alinea comentarios a la derecha del código, o listas de parámetros de funciones, o expresiones complejas multilínea, o cosas de esa naturaleza, quiere que su hermoso trabajo se vea bien para todos . Si usa pestañas y permite que las personas configuren sus pestañas de manera diferente, romperán la alineación para todos, excepto los casos más simples de sangría de código.

Además, es claramente obvio que todos en el mundo deberían usar vim, lo que hace que sea trivial sangrar, desangrar y navegar a través de "tabulaciones" incluso en archivos con sangría espacial.

Las pestañas son la opción natural y ortodoxa, ya que, por definición, se utilizan para la sangría.

Desafortunadamente, las pestañas se implementan de manera desigual, por lo que la única solución del mundo real es 4 espacios.

Obviamente necesitas un enfoque combinado.

Si comparte código con otros desarrolladores, necesita estandarizar, y como eso es imposible (koff koff), debe hacer que todos hagan cuatro espacios.

Entonces necesita un editor que sea lo suficientemente inteligente como para no ser estúpido al respecto, para saber que debe tratar una línea con cuatro espacios al frente como si tuviera sangría. Cualquier IDE moderno o editor de programadores puede hacer fluir automáticamente el código con espacios en lugar de pestañas.

¿Por qué alguien no puede implementar esto?

• el código se almacena en un formato compacto beneficioso para el sistema en cuestión
• a medida que cada desarrollador abre el código, se formatea exactamente como lo quiere
• cuando hayan terminado con él, de vuelta al formato compacto

Todos están contentos ya que todos ven su propio formato

¿Eso es tan difícil?

Espacios o pestañas: lo que Atwood realmente dice es elegir una cosa y ser coherente en su proyecto. El único santo grial del formato de código es asegurarse de que sea coherente para que el psicópata que mantiene su código después de usted no se sienta obligado a remediar la situación de forma permanente.

Dicho esto, si está trabajando en Python o en cualquier otro lenguaje donde el espacio en blanco es una construcción de programación real, no puedo imaginar el uso de pestañas.

Soy un tipo de hombre de 4 espacios, las pestañas simplemente no son consistentes.

Aparentemente las pestañas estropean cosas en Delphi, así que no uso pestañas en Delphi.

Sin embargo, hago todo lo demás con Emacs y siempre uso pestañas porque mis pestañas van exactamente donde quiero que vayan.

La respuesta es que no puede haber un solo carácter de sangría adecuado para cada situación. El formateo con caracteres es inflexible y puede causar conflictos cuando se utilizan diferentes estilos dentro de un equipo.

El único método para formatear código de manera impecable y flexible con diferentes estilos de formateo es hacerlo virtualmente, es decir, sin caracteres de sangría. Sin embargo, el único editor de código que sé que admite esto es el que se usa en el ejemplo a continuación:

Para demostrar el formato virtual , la captura de pantalla a continuación es de un editor XSLT * que usa este método de sangría (también hay un video corto aquí ). Todos los caracteres en el XSLT se han resaltado en amarillo, con fines ilustrativos, para permitir que las únicas pestañas o caracteres de espacio en el contenido se vean claramente. La sangría del código es manejada por el sistema de renderizado del editor ajustando el margen izquierdo (que tiene un fondo blanco).

Los únicos caracteres de espacio iniciales preceden a las líneas de Libros , ya que se trata de contenido de texto literal, no de código, estos caracteres de espacio deben conservarse.

Con el formato virtual, usted elige el ancho de sangría que se adapte al entorno y al estilo de sangría sin afectar los caracteres del archivo fuente. Incluso puede establecer el ancho de sangría en 0, si necesita una vista plana del código como se muestra a continuación:

Para contrastar esto con el formato de caracteres de espacio, el mismo XSLT abierto en un editor sin formato virtual se transforma mediante el formateador automático de ese editor a esto:

Los bloques amarillos en blanco más grandes en la captura de pantalla anterior muestran claramente los caracteres de espacio agregados por el formateador del editor convencional. Desafortunadamente, estos no se pueden distinguir del contenido real, por lo que el XSLT tendría que modificarse para corregir este problema.

Resumen

XSLT es posiblemente un caso extremo, pero este principio es válido para muchos lenguajes de programación: los caracteres se deben usar para el contenido y se debe buscar un método alternativo cuando se trata de formatear.

** Divulgación: el editor XSLT con formato virtual fue desarrollado por mi propia empresa *

No mencionado hasta ahora: hay lenguajes (Python, Haskell) donde la sangría es importante. Pero 1 carácter cuenta como 1 carácter, ya sea un espacio o una pestaña, por lo que la sangría que ve el compilador puede no ser la misma que ve en la pantalla si usa pestañas.

Por lo tanto, en idiomas como Haskell, los espacios son imprescindibles. En Makefiles, TABS son imprescindibles. En todos los demás, es una cuestión de gusto personal y hoy en día no es un gran negocio: cada editor decente tiene un comando "(principales) pestañas a espacios" y "espacios (principales) a pestañas".

Solía ​​usar espacios, pero últimamente he estado usando pestañas puramente porque eso fue lo que Eclipse estaba configurado cuando finalmente me di cuenta. Todos los demás desarrolladores de mi equipo usan Eclipse, por lo que tenía sentido estandarizar las pestañas cuando nos dimos cuenta de que ya las habíamos estado usando durante años y no había razón para molestarnos en cambiar a espacios. Me ha sorprendido lo poco que ha sido un problema.

Establecer el tamaño de la pestaña que se muestra en 3 o 5 caracteres en su IDE simplifica enormemente la distinción entre las secciones de código que están sangradas por espacios (casi siempre 4 en estos días) y las que están sangradas por pestaña.

Ya se han dado muchos argumentos, pero nadie mencionó hacia dónde podríamos dirigirnos en el futuro .

Pestañas ni espacios!

Idealmente, el código debe considerarse datos y no almacenarse en ningún formato de texto específico. Cualquier desarrollador puede aplicar su propia vista preferida. Además, esta vista no debe limitarse solo al texto , sino que puede incluir tablas, selectores de color y fórmulas matemáticas.

Esta idea no es demasiado descabellada. Fue el editor de programación orientada al lenguaje de JetBrain, Meta Programming System (MPS), que primero me hizo darme cuenta de que esto resuelve toda la discusión, al mismo tiempo que agrega muchas posibilidades adicionales. (Sí, esto es posible con los complementos del editor, pero trabajar en el texto agrega directamente muchas complejidades innecesarias, en oposición al enfoque que adopta MPS).

A diferencia de las pestañas y los espacios, existen pequeñas desventajas que se pueden mencionar para trabajar directamente en árboles de sintaxis abstracta . Todo lo que se necesita es que la tecnología madure a un producto comercialmente viable. Los primeros signos de esto están apareciendo. Desarrollado en gran parte sobre MPS, un editor de ActionScript comercial, se creó Realaxy .

¡Me encantaría ver a uno de los grandes jugadores saltar sobre el concepto de esta tecnología y ver qué sucede!

Ninguno de los dos es mejor ni peor. Lo único importante es ser consistente.

Si eres un equipo de uno, elige lo que quieras personalmente. Considere cuál es el comportamiento predeterminado de su editor favorito, pero elija lo que quiera.

Si estás en un equipo, haz lo que hace el equipo. Período.

En mis diversos trabajos he usado dos espacios, cuatro espacios, ocho espacios, pestañas, espacios y pestañas, creo que también podría haber usado un espacio. Le digo a mi editor qué hacer, luego no lo pienso otra vez, el editor resuelve los detalles.

La única otra cosa es asegurarse de elegir un editor inteligente. Emacs o vi? Ahora que es una guerra santa, estoy dispuesto a pelear :-)