¿Cuáles son los inconvenientes de las pestañas elásticas? [cerrado]

81

Mire aquí: una guerra santa típica en las pestañas frente a los espacios .

Ahora mira aquí: tabstops elásticos . Se resolvieron todos los problemas y se agregaron varios comportamientos muy útiles.

¿Semencionantabstopselásticosinclusoenladiscusióndetabsvsespacios?Porquéno?¿Hayinconvenientesenlaideadetabstopelásticatanseriaquenadieloshaimplementadoenuneditorpopular?

EDIT:Medisculpoporponerdemasiadoénfasisen"por qué no se mencionan". Eso no era realmente lo que pretendía; esa pregunta es posiblemente incluso fuera de tema. Lo que realmente quiero decir es, ¿cuáles son los mayores inconvenientes de esto que impiden una adopción más amplia de una idea obviamente beneficiosa? (en un mundo ideal donde todo lo soporta ya)

(Resulta que ya hay una solicitud en Microsoft Connect para un Implementación de Visual Studio de tabulaciones elásticas , y una solicitud de en Eclipse también. Además, hay una pregunta sobre otros editores que implementan tabstops elásticos )

    
pregunta Roman Starkov 28.02.2012 - 11:46

12 respuestas

32

Las guerras santas son subjetivas

Las pestañas elásticas de

Nick son un concepto sorprendente que podría ayudar a mucha gente a ponerse de acuerdo sobre una solución viable, aunque dudo mucho que termine esta Guerra Santa: después de todo, también es una cuestión de gustos y muchos programadores no se moverán ni un centímetro de su posición en este asunto, incluso a costa del compromiso. Así que esa sería una primera razón.

Por ejemplo, mucha gente en el lado de los "espacios" aún no estará de acuerdo, ya que requiere una lógica adicional en su software para una representación decente (por ejemplo, simplemente ver un conjunto de cambios en su Webview de SCM).

Problemas de implementación

Pero la razón más obvia es simplemente su barrera técnica de entrada : es un concepto fundamentalmente diferente de lo que se ha implementado para un número de años (si no décadas) en IDEs y editores de texto. Requeriría volver a escribir algunos de ellos para procesar líneas en una forma bastante diferente, lo que dificulta que los sistemas más antiguos y más grandes tengan una mayor probabilidad de sufrir un acoplamiento profundo y estrecho en su código de procesamiento de línea. Sin embargo, es mucho más fácil hacerlo cuando empiezas desde cero (piensa en la demo de Nick o en Go del paquete tabwriter ).

Para una anécdota personal, recuerdo que me acerqué al autor hace un rato para preguntar si había algún apoyo de emacs a la vista, y en este caso particular, mencionó esto como la razón por la que no era trivial. También pidió ayuda a la comunidad para ayudar a implementar esta característica y llevarla a las masas.

¿Nos importa lo suficiente?

Una tercera razón, es que algunos desarrolladores no están tan preocupados por el tema y realmente no les importa tanto que harían todo lo posible para apoyar el esfuerzo. En la mayoría de los casos, el conflicto entre espacios y tabulaciones no es un bloqueador de negocios, por lo que no hay tanta unidad detrás del problema.

Si lo deseas, tendrás que luchar por ello. Lo cual es factible en software de código abierto. Y si cambias lo suficiente, los de código cerrado tendrán que correr el riesgo de perder parte de su base de usuarios, si es una parte muy pequeña de ella.

Entonces, si lo quieres, dale una mano a Nick.

    
respondido por el haylem 28.02.2012 - 17:18
35

Muchas veces he tenido que luchar con un procesador de textos para que el documento se vea como quiero sin una regla automática oculta que controla la ubicación de mis palabras. No quiero pasar ni un segundo tratando de averiguar por qué el editor insiste en colocar esas palabras allí.

    
respondido por el mhoran_psprep 28.02.2012 - 14:12
27

Esta es la primera vez que escucho de eso. No estoy seguro de si son una buena idea pero parecen de poca utilidad ya que tenemos herramientas (como sangría) que ya dan formato al código automáticamente.

¿Qué sucede cuando abro tus tabstops elásticos inteligentes en vim y lo edito? ¿La pestaña se limpia automáticamente o te queda un lío?

Los principales inconvenientes, como los veo, son posiblemente diferencias, control de versiones y no son compatibles con editores que no los admiten. Tal vez haya una gran cantidad de modificación de código para respaldarlos y hay cosas más importantes que la característica "otra cosa más de la pestaña para dar formato al código". Después de todo, todos podemos usar indent que hace todo lo anterior si la memoria sirve.

    
respondido por el Sardathrion 28.02.2012 - 12:04
13

Para ser honesto, no los encuentro tan útiles una vez que superas la emoción inicial. Por ejemplo, no me gustan los comentarios al final de una línea de todos modos, siempre coloco mis comentarios en una línea separada. Con eso, las lengüetas elásticas pierden su uso principal.

Después de eso, por supuesto, puede seguir usándolos para alinear los argumentos de la función (y los parámetros) y las largas listas de asignaciones.

Pero para el primero, tiendo a sangrar todos los argumentos en un nivel adicional y eso funciona completamente bien conmigo:

void foo(
    int x,
    int y,
    string z
)

Y no veo que ninguna tenga que cambiar eso.

Y en cuanto a alinear las tareas, no hago eso. Pongo espacios individuales alrededor de las tareas, eso es todo. También tiendo a no agrupar muchas asignaciones, por lo que rara vez hay problemas de legibilidad.

En resumen, las pestañas elásticas tienen una utilidad absolutamente cero para mí. Esta es, por supuesto, una preferencia muy personal que puede variar, pero creo que funciona bien y creo que la falta de apoyo para las pestañas elásticas se debe a que otras personas piensan de manera similar.

Si un editor los implementara, todavía no los usaría.

    
respondido por el Konrad Rudolph 28.02.2012 - 17:07
13

Un inconveniente es que no funciona si desea alineación en un grupo de líneas y luego sangría en el siguiente, ya que agrupa las tabulaciones de las líneas adyacentes.

def foo( bar,
         xyzzy ):
         wibble() # Too much indentation

Lo que quería:

def foo( bar,
         xyzzy ):
    wibble()

Para los lenguajes de rizo, esto podría ser un problema menor, ya que generalmente se puede resolver colocando el soporte de apertura en una línea propia (como en la animación), pero para los lenguajes sensibles al espacio en blanco, esto se convierte rápidamente un dolor, y terminas teniendo que volver a usar espacios.

    
respondido por el hammar 28.02.2012 - 20:16
11

¿Por qué no hacemos que el carácter de tabulación vertical (VT, ASCII 11) sirva para indicar el uso de tabstops elásticos? Sirve a ningún propósito en ningún lenguaje de programación convencional, sin embargo, se analiza como un espacio en blanco válido en todos ellos, AFAIK.

Esto significaría que el uso de tabulaciones elásticas ya no es una convención externalizada (por ejemplo, "este archivo fue formateado con tabulaciones elásticas, actívelo"), pero es algo a lo que se opta caso por caso.

Los editores de texto existentes generalmente muestran un glifo o un solo espacio en lugar de una pestaña vertical. Esto no es ideal, pero es un pequeño precio a pagar, OMI.

    
respondido por el Richard Nelson 12.01.2013 - 00:12
10

No se mencionan porque no están implementados en la mayoría de los IDE de los editores de texto; son una novedad de poca utilidad real en un proyecto.

Se han utilizado espacios para diseñar la programación desde los días de las tarjetas perforadas. Las pestañas llegaron y, obviamente, alguien pensó que eran una buena idea (se equivocaron: p).

En los días en que la mayoría de los editores modernos pueden convertir las pestañas en espacios automáticamente ... son bastante inútiles.

Tener que instalar otra herramienta para lidiar con algo tan trivial como tabs vs espacios ciertamente no me atrae, y no creo que lo sea para la mayoría de mis colegas.

    
respondido por el TZHX 28.02.2012 - 11:52
4

Creo que les resultaría muy útil si los IDE los apoyaran (¡Microsoft!). Una vez que las personas descubren que pueden abofetear sus cajas de flores en el costado y hacer que sean fáciles de leer, lo harán. Es posible que se agreguen más comentarios al código fuente de forma repentina (lo que solo puede ser bueno).

Supongo que también podríamos agregar "información sobre herramientas" de comentarios a la lista de 'sería bueno si ...', por lo que sus grandes bloques de comentarios podrían ocultarse y verse fácilmente cuando sea necesario. Tal vez también podríamos tener bloques de comentarios que forman parte de la documentación (no del tipo del castillo de arena, fragmentos de documentación legibles para el usuario que se incrustaron en el código, no solo los encabezados de los métodos)

Desventajas: puede hacer que las diferencias de origen se vean mal si parece que se modificaron varias líneas cuando en realidad solo se modificó 1 (si el editor guardó el archivo con las pestañas convertidas en espacios). O, si la pestaña elástica se implementó con un solo carácter (o más probablemente, 2 tabulaciones), ver su fuente fuera del editor podría verse mal.

Creo que me gusta la idea, sin embargo, 'pestaña' al final de una línea elástica el bloque de comentarios y alinea todos los comentarios en las líneas subsiguientes (que tienen el espaciado de doble pestaña) en consecuencia.

    
respondido por el gbjbaanb 28.02.2012 - 12:09
3

Así es como lo veo: si la mayoría de las herramientas populares ya admitieran tabulaciones elásticas, mucha gente las usaría. Lo mismo sucedió con el modo de navegación / edición de vi, con el resaltado de sintaxis y más tarde con Intellisense. En cada caso, la sabiduría establecida fue que no es útil o no es necesario, pero se implementó y despegó.

Las tabstops elásticas tienen, por supuesto, un impacto relativamente bajo. La mayoría de las personas están lo suficientemente satisfechas con el status quo y por eso no les importa. Un razonamiento similar se aplica a muchas situaciones en las que algunas personas simplemente están contentas con lo que tienen y no ven ninguna razón para cambiar a algo más avanzado. En otras palabras, el mayor problema con tabstops elásticos es el mismo que para casi cualquier otra buena idea: necesita ganar tracción.

Pero eso no significa que la característica no se pueda adoptar de forma incremental. Cada lenguaje de programación único se adoptó de manera incremental, aunque un equipo completo requiere un nuevo compilador y un nuevo IDE para comenzar a usarlo. Lo mismo ocurre con cada arquitectura de hardware y muchos otros ejemplos. Tampoco es el caso que la falta de integración con las herramientas existentes sea un factor decisivo: lo mismo ocurre, por ejemplo, con el "formato de difusión unificada", que sustituyó de manera incremental a un formato anterior menos legible que aún se entendía con herramientas automatizadas. (como el parche). Esas herramientas se han actualizado con el tiempo.

Aprecio los problemas de interoperabilidad que otros han mencionado, pero a pesar de ellos, seguramente habrá equipos (como el mío) que adoptarían esto sin dudarlo, en nuestra totalidad. Las herramientas externas, como diferenciar, fusionar, etc. inicialmente no lo admitirán, pero haremos nuestra parte para alentar a los proveedores a incluir la característica. Así es como siempre se ha progresado. Requiere algunos dolores por un período transitorio temporal, pero al final, vale la pena.

    
respondido por el Timwi 28.02.2012 - 16:21
2

El mayor problema que tendría con él es el espacio inconsistente en toda la documentación. Sé que como programador me molestaría ver un bucle o una declaración en la sangría "estándar" y luego observar las diferentes sangrías. Sé que personalmente me gusta ver todas mis llaves alineadas a lo largo de toda la documentación, no solo en el bloque de código que estoy viendo.

En general, creo que es una buena idea, pero personalmente, no me gustaría.

    
respondido por el Falcon165o 28.02.2012 - 15:32
1

Acabo de probar la implementación de tabstops elásticas de jEdit, que funciona sorprendentemente bien con los lenguajes de programación con los que estoy familiarizado (principalmente HTML / XML y lenguajes tipo C). Sin embargo, con el código Python, aquí se muestra cómo se representa (espacios utilizados en lugar de pestañas para ilustrar cómo se alinean las cosas):

def foo(x):
             '''<1 tab before the docstring.
No tab       <tab
No tab       <tab
             <tab  <another tab
             <tab  <another tab
             <tab'''
             if 1 or 2:    #<Tab before this comment
                           yield True

Para un lenguaje como Python que se basa en el espaciado, este es un factor decisivo a menos que deshabilites la funcionalidad proporcionada por tabstops elásticos. Editores como Vim y Emacs hacen que la desactivación de la mayoría de los tipos de funcionalidad sea simple si conoce el nombre de la opción y cómo deshabilitarla, pero esta funcionalidad debería estar deshabilitada para códigos como el anterior.

Dicho esto, es genial para x86 ASM, C, C ++, Go, XML, HTML y otros que no dependen tanto del espacio en blanco:

import (
    "fmt"    // We love formatting functions.
    "io"     // Because I/O is useful.
    "os"     // Can't open a file without os.Open!
)

type Foo struct {
    Field1              int          // This is properly aligned
    ReallyLongField2    string       // with this.
    privateField        io.Reader    // Elastic tabstops are great for Go.
}

Diré que los dialectos Lisp como Scheme tienen sus propias convenciones que también harían que las tabulaciones elásticas produzcan código "feo". Si cambio mi configuración de tabulación para coincidir con la convención de 2 columnas e inserto tabulaciones en lugares inusuales (entre una función y sus argumentos):

(let loop ((n 1))
  (if  (> n 10)
        '()
        (cons  n
               (loop (+ n 1)))))

vs. el más legible:

(let loop ((n 1))
  (if (> n 10)
      '()
      (cons n
            (loop (+ n 1)))))

Por supuesto, este no es tan malo como el ejemplo de Python, pero definitivamente reduce la legibilidad del código. Si bien disfruto mucho de la funcionalidad al codificar en algo como C # o C ++, aborrezco la funcionalidad al codificar en un lenguaje como Python o Scheme donde el espacio en blanco es funcional y / o visualmente útil. Las tabulaciones elásticas fueron creadas específicamente para ser útiles sin requerir una utilidad de sangrado separada, pero claramente no está diseñada para todos los lenguajes de programación.

    
respondido por el Chrono Kitsune 05.10.2015 - 03:52
0

Emacs ya maneja la sangría en presencia de paréntesis no cerrados, y alineará automáticamente wilma con fred . No tengo idea de por qué Eclipse no hace lo mismo. Ok, tengo una idea, pero es poco complementaria.

También puedes hacer que Emacs alinee el comentario, sin muchos problemas, pero AFAIK nadie, pero tú siempre has querido eso.

    
respondido por el kevin cline 28.02.2012 - 18:44

Lea otras preguntas en las etiquetas