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


83

Mira aquí: una típica guerra santa en pestañas vs espacios .

Ahora mira aquí: topes elásticos . Se resolvieron todos los problemas y se agregaron un montón de nuevos comportamientos muy útiles.

lengüetas elásticas

¿Se mencionan incluso las pestañas elásticas en esa discusión pestañas vs espacios? Por qué no? ¿Hay inconvenientes en la idea de pestañas elásticas tan serias que nadie las haya implementado en un editor popular?

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

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


44
Esta sería una gran pregunta para ux.stackexchange.com
JonnyBoats

11
Nunca se mencionan en la discusión "pestañas versus espacios" porque casi no hay forma de que un programador que trabaja use estas cosas. Tal vez si tuviera una implementación de Eclipse, VS, gvim y emacs, eso podría cambiar.
Paul Tomblin

2
Realmente me gusta la idea, pero solo cuando vives con ella durante un mes más o menos, realmente sabes cuáles son las trampas. Como todo, se garantiza que habrá algunos casos en los que haga cosas que no esperarías ...
Chris Burt-Brown

3
@ ChrisBurt-Brown Eso siempre es un riesgo, sí. IntelliSense también tiene sus dificultades, como la sustitución de texto cuando no lo desea. En general, sin embargo, IntelliSense en C # fue una gran victoria.
Roman Starkov

44
Quiero esto en el bloc de notas ++ ... Quiero esto ahora
Ben Brocka

Respuestas:


32

Las guerras santas son subjetivas

Las pestañas elásticas de Nick son un concepto increíble que podría ayudar a muchas personas a ponerse de acuerdo sobre una solución viable, aunque dudo mucho que termine por completo esta Guerra Santa: después de todo, es también una cuestión de gustos y muchos programadores no se moverán. pulgadas de su posición sobre este asunto, incluso a costa del compromiso. Entonces esa sería una primera razón.

Por ejemplo, a muchas personas del lado de los "espacios" aún no les gustará, ya que requiere una lógica adicional en su software para una representación decente (por ejemplo, simplemente viendo un conjunto de cambios en la vista web de su SCM).

Problemas de implementación

Pero la razón más obvia es solo su barrera técnica de entrada : es un concepto fundamentalmente diferente de lo que se ha implementado durante varios años (si no décadas) en IDE y editores de texto. Sería necesario reescribir algunos de ellos para procesar líneas en un fasion bastante diferente, lo que dificulta a los sistemas más grandes y antiguos que tienen una mayor probabilidad de sufrir un acoplamiento profundo y estrecho en su código de procesamiento de línea. Es, sin embargo, mucho más fácil de hacer cuando se empieza desde cero (pensar en demostración de Nick o de Go 's tabwriter paquete).

Para una anécdota personal, recuerdo acercarme al autor hace un tiempo para preguntar si había algún soporte de emacs a la vista, y en este caso en particular, mencionó esto como la razón por la cual no era trivial. También pidió ayuda de 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 obsesionados con el asunto y realmente no les importa tanto que harían un esfuerzo adicional para apoyar el esfuerzo. En la mayoría de los casos, el conflicto espacios-vs-pestañas no es un bloqueador de negocios, por lo que no hay tanto impulso detrás del problema.

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

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


(fuera del tema) A menudo me pregunto cómo otras características "esto es agradable pero muy poco importante" alguna vez se convierten en productos como Visual Studio. Parece que alguien en el equipo simplemente encontró el tiempo para implementarlo por razones personales. Piense en escribir en varias líneas a la vez en Visual Studio, por ejemplo; No es como si decenas de miles de personas lo pidieran, pero me gusta bastante.
Roman Starkov

3
@romkyns: En cuanto a muchas cosas, se necesita una información privilegiada silenciosa o mil voces gritando en las puertas.
haylem

35

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


11
Yo tampoco. Simpatizo totalmente con este sentimiento, ya que tales reglas realmente también me frustran. Pero esto es diferente de dos maneras. Uno: al igual que las tabstops ahora, no tienes que usarlas si no quieres. Puede dejar solo el texto de sus colegas si los usa. Dos: las pestañas elásticas no tienen reglas ocultas, sino evidentes. El comportamiento es completamente natural, quizás incluso más natural que las tabstops tradicionales, que ocurren en una posición arbitraria, generalmente irrelevante, dentro del texto. Es por eso que ya nadie usa tabstops para otra cosa que no sea la sangría.
Timwi

10
@Timwi: La pregunta era enumerar los inconvenientes. Yo hice.
mhoran_psprep

14
Puede que no sea obvio por el GIF, pero la única solución es que cuando presionas "TAB", lo que viene después saldrá correctamente alineado verticalmente. No es nada como un procesador de textos. Simplemente pruebe la demostración interactiva real en el enlace que publiqué, y verá cuán natural es.
Roman Starkov

3
@mhoran_psprep: Muy bien, agradezco su aporte. Supongo que estábamos viendo diferentes interpretaciones de la pregunta. Estás enumerando inconvenientes de ti mismo usando la función, mientras que pensé que se trataba de inconvenientes de introducir la función (es decir, hacerla disponible y no obligatoria ).
Timwi

27

Esta es la primera vez que escuché sobre eso. No estoy seguro de si son una buena idea, pero parecen de poca utilidad ya que tenemos herramientas (como sangría) que ya formatean el código automáticamente.

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

Los principales inconvenientes, tal como los veo, posiblemente están rompiendo diferencias, control de versiones y no son compatibles con editores que no los admiten. Tal vez se requiera mucha modificación del código para admitirlos y hay cosas más importantes que la función "otra pestaña para formatear el código". Después de todo, todos podemos usar lo indentque hace todo lo anterior si la memoria sirve.


99
Qué actitud de pensar hacia atrás. ¡No avancemos porque las herramientas antiguas y obsoletas favoritas de las personas aún no pueden hacer frente ! (La ironía, por supuesto, es que estas herramientas (como vim) son de código abierto, por lo que si fuera realmente importante para usted, podría (y probablemente debería ) agregarle soporte elástico para tabstop)
Timwi

14
@Timwi: Te estás perdiendo el punto que estaba haciendo. ¿Qué sucede cuando su archivo de código es analizado por algo que no es consciente de las pestañas elásticas? ¿Terminas con un desastre o pueden hacer frente? ¿Qué pasa con el control de versiones y diffs? Solo desear que todas las herramientas admitieran $ feature no es realista, incluso si esas herramientas son de código abierto.
Sardathrion

14
@Timwi: Asumes que todos encuentran que las tabstops elásticas son tan increíbles como crees que son. Esto puede que no sea verdad.
Sardathrion

77
@Sardathrion tiene razón. ¿Qué sucede cuando tengo que acceder de forma remota a mi servidor * nix sin un sistema de ventanas instalado y necesito examinar algún código con Vim / Emacs / Pico / Whatever? Si hay un mecanismo para que sea legible, estaría bien ... de lo contrario sería una pesadilla. No veo que el beneficio de la lengüeta elástica deje de ser tan beneficioso de todos modos. Ya puedo autoformar mi código para que se vea como debería en los IDE que uso.
Plataforma

77
El punto de control de la versión es bueno: no creo que la gente aprecie un editor que silenciosamente comienza a cambiar la ubicación / formato de los comentarios en código arbitrariamente lejos del código que están modificando (vea la sección magenta en la animación de OP gif). Sería útil tener una implementación de referencia para jugar, pero lo que veo hasta ahora no es notable: emacs ya hace mucho de esto, solo con un par de pulsaciones de teclas adicionales (lo que podría decirse que es algo bueno).
mcmcc

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 pongo mis comentarios en una línea separada. Con eso, las pestañas elásticas pierden su uso principal.

Después de eso, por supuesto, aún puede usarlos para alinear argumentos de función (y parámetros) y largas listas de tareas.

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

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

Y no veo ninguna necesidad de cambiar eso.

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

En resumen, las pestañas elásticas tienen absolutamente ninguna utilidad para mí. Por supuesto, esta es una preferencia muy personal que puede variar, pero creo que funciona bien y supongo que la falta de soporte para 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.


Apreciado. Parece que también podría usar una fuente de ancho variable si lo desea, ya que de todos modos no alinea nada más que el comienzo de la línea. Visual Studio tiene bastante buen soporte para esto, en realidad, y el aumento de legibilidad es bueno.
Roman Starkov

1
@romkyns Tuvimos discusiones sobre eso y en el curso de una intenté usar una fuente proporcional para programar por algún tiempo. El resultado fue que las fuentes monoespaciadas funcionan mejor, incluso sin tener en cuenta la sangría. Aparte de eso, actualmente estoy trabajando exclusivamente en Vim y la consola, ninguno de los cuales probablemente admitirá fuentes proporcionales.
Konrad Rudolph

1
@romkyns Dicho esto, estos problemas son solucionables (o quizás incluso resueltos, con una fuente proporcional diseñada para la programación). Pero todavía no veo realmente la necesidad.
Konrad Rudolph

13

Un inconveniente es que no funciona si desea la alineación en un grupo de líneas y luego la 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 llaves, esto podría ser un problema menor, ya que generalmente puede resolver esto poniendo la llave 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 en un dolor, y terminas teniendo que recurrir al uso de espacios.


Convenido. La implementación de Nick no funciona muy bien para lenguajes como Python.
Roman Starkov

3
¿Por qué no funcionaría esto? Esto no es una limitación fundamental, el algoritmo solo necesita ser consciente del lenguaje. Pero, hasta cierto punto, esto es cierto incluso hoy, Vim, por ejemplo, define diferentes reglas de sangría según el idioma. Esto podría acomodar fácilmente la sangría de Python.
Konrad Rudolph

1
@KonradRudolph No, no pudieron. El atractivo de los tabuladores elásticos es la capacidad de sangrar / desangrar automáticamente grupos de texto juntos. Un ejemplo simple es el final de una declaración "if": Intenta desangrar porque está saliendo de la declaración, pero los separadores elásticos "inteligentes" deciden que también quiso desangrar la línea o las dos anteriores, etc. y así sucesivamente ... Y si tiene que agrupar explícitamente el texto, entonces, ¿cuál es el punto? Es más trabajo hacer eso que arreglar las sangrías usted mismo ...
Izkata

1
@Izkata Unindenting manualmente (simplemente) simplemente finalizaría el grupo actual. ¿Por qué alguna vez controlarías la sangría con la pestaña elástica se detiene manualmente? No lo haría, por lo que el algoritmo sabe que cuando lo hace, es finalizar un bloque, no desangrar el bloque anterior.
Konrad Rudolph

1
Oh, buen punto. Hmm ... ¿tal vez podrías hacer doble sangría en los argumentos? Entonces, wibble()¿tendría una sola sangría y, por lo tanto, no estaría alineada con los argumentos de la función?
Ajedi32

12

¿Por qué no hacemos que el carácter de tabulación vertical (VT, ASCII 11) sirva para indicar el uso de tabuladores elásticos? No sirve para nada en ningún lenguaje de programación convencional, pero se analiza como un espacio en blanco válido en todos ellos, AFAIK.

Esto significaría que el uso de topes elásticos ya no es una convención externa (por ejemplo, "este archivo fue formateado con topes elásticos, actívelos"), sino algo en lo que opte 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, sino un pequeño precio a pagar, en mi opinión.


10

No se mencionan porque no se implementan en la mayoría de los IDE de los editores de texto; son una novedad de poco uso real en un proyecto.

Los espacios se han utilizado para diseñar la programación desde los días de las tarjetas perforadas. Las pestañas aparecieron y alguien obviamente 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 las pestañas frente a espacios ciertamente no me atrae, y no creo que lo haga para la mayoría de mis colegas.


He borrado los comentarios ya que descendían en insulto.
ChrisF

1
Solo pensé en señalar que, la razón principal por la que me gusta la idea de tabulaciones elásticas no es porque resuelva el problema de tabulaciones vs espacios, sino por el comportamiento que se muestra en el GIF en la pregunta original; Alineación automática, sin dolor. Además, para los diferenciales de VCS existe el beneficio adicional de que no hubo cambios de espacio en blanco requeridos en ese ejemplo.
Ajedi32

"Tener que instalar otra herramienta más ..." no es un argumento lo suficientemente bueno ... Como si ya no se estuvieran utilizando suficientes herramientas.
Milind R

@MilindR Ya sea que lo consideres un argumento lo suficientemente bueno o no, es la razón por la que (en ese momento hace tres años) no tendría interés en esto. El uso de muchas herramientas que hacen algo útil no es una razón para agregar otra que, realmente, no agrega nada a su entorno.
TZHX

Actitudes como esta son las razones por las cuales compañías como MS deciden forzar a los usuarios a usar nuevos UX ... Me estremezco al pensar qué sucedería si se aplicara la misma actitud a los disquetes -> transición de CD.
Milind R

4

Creo que encontrarían mucho uso si los IDE los admitieran (¡Microsoft!). Una vez que las personas descubrieron que podían abofetear sus cajas de flores a un lado y hacer que fueran legibles, lo harán. Es posible que de repente se agreguen más comentarios al código fuente (que solo puede ser algo bueno).

Supongo que también podríamos agregar "sugerencias de herramientas" de comentarios a la lista de 'sería bueno si ...', para que sus grandes bloques de comentarios puedan ocultarse y verse fácilmente cuando sea necesario. Quizás también podríamos tener bloques de comentarios que formen parte de la documentación (no material tipo castillo de arena, fragmentos de documentación legibles por el usuario adecuados que se incrustaron en el código, no solo los encabezados del método)

Desventajas: puede hacer que sus diferencias de fuente se vean mal si un grupo de líneas pareciera haber cambiado cuando realmente solo se modificó 1 (si el editor guarda 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 pestañas), ver su fuente fuera del editor podría verse mal.

Sin embargo, creo que me gusta la idea, 'pestaña de pestaña' al final de una línea elastica el bloque de comentarios y alinea todos los comentarios en líneas posteriores (que tienen el espacio de doble pestaña) en consecuencia.


3

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

Las pestañas elásticas tienen, por supuesto, un impacto relativamente bajo. La mayoría de las personas están suficientemente satisfechas con el status quo y, por lo tanto, 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 topes elásticos es el mismo que para casi cualquier otra buena idea: necesita ganar tracción.

Pero eso no significa que la función no se pueda adoptar de forma incremental. Cada lenguaje de programación se adoptó de forma incremental, a pesar de que todo un equipo requiere un nuevo compilador y un nuevo IDE para comenzar a usarlo. Lo mismo es cierto para cada arquitectura de hardware y muchos otros ejemplos. Tampoco es el caso que la falta de integración con las herramientas existentes sea un obstáculo: lo mismo es cierto, por ejemplo, del "formato de diferencia unificada", que reemplazó gradualmente un formato anterior menos legible que, sin embargo, las herramientas automatizadas entendían. (como parche). Esas herramientas se han actualizado con el tiempo.

Aprecio los problemas de interoperabilidad que otros han mencionado, pero a pesar de ellos, ciertamente habrá equipos (como el mío) que adoptarían esto sin dudarlo, en su totalidad. Las herramientas externas como la diferenciación, la fusión, etc., inicialmente no lo admitirán, pero haríamos nuestra parte para alentar a los proveedores a incluir la función. Así es como siempre se ha progresado. Requiere algunos dolores durante un período de transición temporal, pero al final, vale la pena.


El argumento C vs C ++ parece un poco equivocado. Si bien puede ser cierto que este es el caso de "algunas personas" (como usted dijo correctamente), existen razones obvias para apegarse a C o favorecer C ++ dependiendo de la situación. El tamaño del tiempo de ejecución de C ++ es uno de ellos, en una configuración predeterminada.
haylem

Estoy con haylem. Su punto sería más sólido sin la comparación C-versus-C ++. Son idiomas muy diferentes. En mi opinión, C es para la programación de sistemas y otros trabajos de bajo nivel donde se necesita mucho control (una VM, por ejemplo). C ++ es más para aplicaciones de nivel medio donde la abstracción es útil para gestionar la complejidad (espacios de nombres, contenedores STL y algoritmos, plantillas), pero el rendimiento sigue siendo una preocupación (los juegos son el ejemplo más visible).
Jon Purdy

@haylem: Gracias por los comentarios. He eliminado la referencia a C / C ++.
Timwi

@ JonPurdy: Gracias por los comentarios. He eliminado la referencia a C / C ++.
Timwi

2

El mayor problema que tendría con él es un espaciado inconsistente en toda la documentación. Sé que, como programador, me molestaría ver un bucle o una declaración con sangría 'estándar' y luego notarlo en diferentes sangrías. Sé que personalmente me gusta ver todas mis llaves alineadas en 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.


1

Acabo de probar la implementación de jEdit de tabstops elásticos, que funciona increíblemente bien con los lenguajes de programación con los que estoy familiarizado (principalmente HTML / XML y lenguajes similares a C). Sin embargo, con el código Python, así es como 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, esto es un factor decisivo a menos que desactive la funcionalidad proporcionada por tabulaciones elásticas. Los editores como Vim y Emacs simplifican la deshabilitación de la mayoría de los tipos de funcionalidad si conoce el nombre de la opción y cómo deshabilitarla, pero se requeriría deshabilitar esta funcionalidad para código como el anterior.

Dicho esto, es ideal 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 de Lisp como Scheme tienen sus propias convenciones que también harían que las tabstops elásticas representen un código "feo". Si cambio la configuración de mi tabulación para que coincida con la convención de 2 columnas e inserte tabulaciones en lugares inusuales (entre una función y sus argumentos):

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

vs. los más legibles:

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

De acuerdo, este no es tan malo como el ejemplo de Python, pero definitivamente reduce la legibilidad del código. Si bien disfruto mucho 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 pestañas elásticas se crearon específicamente para ser útiles sin requerir una utilidad de sangría separada, pero claramente no está destinado a todos los lenguajes de programación.


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 no es complementaria.

También podría hacer que Emacs alinee el comentario, sin muchos problemas, pero AFAIK nadie más que usted siempre ha querido eso.


2
Solo puedo interpretar su última oración como curricán, ya que obviamente al menos otro tipo lo quería bastante como para crear una página bien discutida, una implementación de Java y un GIF para mostrar por qué es bueno. Si lees las respuestas, verás que Nick tampoco está solo. Oh espera, mira aquí también.
Roman Starkov

Por cierto, ¿Emacs vuelve a sangrar a wilmamedida que realiza ediciones, como cambiar la longitud del nombre de la función? Si lo hace, eso está bastante cerca de lo que hacen las pestañas elásticas.
Roman Starkov

@romkyns: No quise ser curricán, solo quería decir que nunca había visto ese estilo de sangría de comentarios en EMACS. En general, EMACS no vuelve a sangrar varias líneas a medida que escribe, pero eso también podría modificarse.
Kevin Cline
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.