¿Cómo te sentirías si tu editor de código formateara tu código mientras escribías, sin pestañas / espacios? [cerrado]

8

Como con la mayoría de las cosas, estoy seguro de que este concepto se ha probado antes, simplemente no me he encontrado con editores que usen lo que he denominado 'formato virtual'. El principio es que hay un margen izquierdo flotante que simula el efecto del espacio de relleno / caracteres de tabulación que el desarrollador o el editor mismo insertan convencionalmente para formatear el código. El editor analiza continuamente el código (incluso cuando está comentado) a medida que escribe y calcula la sangría requerida en función del contexto donde se encuentra cada avance de línea

Estoy desarrollando esta idea trabajando específicamente con un editor XML, ya que XML tiene algunos problemas peculiares con el formato de los caracteres y tiende a estar muy anidado, sin embargo, creo que muchos de los principios aún se mantienen para el código convencional.

¿Ha experimentado la codificación con una herramienta de este tipo o tiene una opinión sobre si ayudaría o dificultaría? ¿Causaría problemas con los sistemas de control de versiones? (detecta y elimina todos los caracteres de relleno existentes)

A menos que lo haya probado, el comportamiento de dicha herramienta es difícil de describir, parece convencional hasta que realmente comienza a editar. Puse un video de screencast que muestra un prototipo en acción que demuestra la edición de XML, cambiando su jerarquía y haciendo operaciones de arrastrar / soltar y copiar y pegar, y luego cómo el formato se rompe / arregla cuando se escriben caracteres no válidos.

Editar Todas las respuestas / comentarios han sido negativos hasta ahora, por lo que para intentar equilibrar el equilibrio, hay que pensar en algunos beneficios del formato virtual:

No más debates sobre estándares de formato, solo coloque saltos de línea donde eso se ajuste a su convención elegida / obligatoria
Cuando el espacio es escaso (en un libro / blog / documentación) puede ajustar las palabras pero aún así obtener una sangría perfecta
Cada bloque de código puede tener un 'controlador de mouse' inmediatamente adyacente al lugar donde comienza, no apretado en el borde de la pantalla; haga clic aquí para seleccionar el bloque completo o el bloque interno
Arrastra, suelta y olvida: se vuelve viable por primera vez
No pasa tiempo reformateando el código de otras personas
No hay código con formato incorrecto (en el sentido de que no hay ninguno, solo el renderizado)
Usar Retroceso en lugar de Ctrl + Retroceso mantiene los dedos en las teclas de guía del teclado
Procesamiento flexible: adapte el formato procesado a su entorno, ¿alguien intentó leer el código en un teléfono móvil / tableta de pantalla pequeña?
Tenga en cuenta que hay aproximadamente un 25% menos de caracteres editables (en una muestra XSLT), ¿eso no tiene beneficios de eficiencia?

Editar - Conclusiones hasta ahora

Los desarrolladores han establecido herramientas y métodos de trabajo que superan eficientemente la mayoría de las desventajas inherentes al uso de caracteres de relleno utilizados para la sangría.
Existe la preocupación de que la eliminación de caracteres de formato afectará negativamente a algunas herramientas de diferenciación.
Los desarrolladores desean la flexibilidad para 'ajustar' el formato de tal manera que el renderizado automático no pueda manejarlo.
La eliminación de espacios / pestañas iniciales significa que se necesita una herramienta 'consciente del código' capaz de formatear el código para revisar dicho código de manera eficiente; un editor de texto sin formato no mostraría formato.
Aquellos que sienten que puede haber algunos beneficios hipotéticos (a la sangría virtual), tienen la opinión de que las desventajas superan esos beneficios potenciales, de manera concluyente .

Editar - Veredicto

La percepción de los obstáculos y los pocos beneficios (si los hay) es tal que no sería prudente para mí, como desarrollador exclusivo, seguir este concepto de edición libre de espacio para los idiomas generales. Sin embargo, para XML / XSLT (debido a su tratamiento especial del espacio en blanco), parece haber al menos algún acuerdo de potencial.

Editar - Producto enviado

A pesar del sentimiento generalmente negativo que se encuentra aquí, seguí adelante y envié al editor. Hice una versión gratuita con la esperanza de que traiga críticas en forma de problemas más concretos, basados en la experiencia real. De manera algo frustrante, no ha habido quejas hasta el momento (de hecho, apenas hay comentarios sobre el volumen de descarga). Me gustaría pensar que esto se debió a que los usuarios se ajustaron tan bien a la idea que lo ven como un "¿y qué?" tipo de característica, pero no hay forma de saber ...

— pgfearo
fuente

Creo que algunos editores de Scheme hacen este tipo de formato sobre la marcha, pero insertando (y eliminando) espacios verdaderos

— Javier

@Javier Debo confesar que no me he encontrado con Scheme. Buscaré esto, mi opinión es que hay algunos idiomas en los que el formato es más crítico / peligroso que otros, por lo que Scheme es posiblemente uno de esos

— pgfearo

Te sugiero que veas Firebug y cómo edita el árbol HTML.

— Lie Ryan

@Lie Ryan - Sí, me gusta el editor de árbol, hasta donde llega. Pero todavía parece que está completando un formulario en lugar de texto de flujo libre, supongo que es porque solo edita atributos, no elementos (en este modo, por lo que puedo decir).

— pgfearo

Para empezar, HTML no es exactamente un texto de flujo libre, pero entiendo lo que quiere decir con ganas de llenar formularios (de hecho, por eso me gusta, las restricciones hacen que sea imposible introducir etiquetas no cerradas / no coincidentes, atributos sin comillas, etc. No usaría un editor XML dedicado si me permitiera escribir XML mal formado). En Firebug puede agregar un nuevo nodo haciendo clic derecho> editar HTML, bastante inconveniente pero suficiente para la edición menor que los desarrolladores web necesitaban. Sin embargo, en un editor más serio, es posible tener un botón / menú contextual / acceso directo para insertar nodos.

— Lie Ryan

6

El mayor problema sería cómo aparecerían los archivos en otras herramientas, especialmente en las herramientas de control de versiones. Los finales de línea son importantes para estas herramientas. No me gustaría ver una pantalla de fusión en la que tengo una clase completa en una línea e intentar fusionar una parte del texto en la columna 347.

— Jeremy
fuente

1

@Jeremy: para aclarar, todos los avances de línea (si están presentes) se conservan solo las pestañas / espacios que se eliminan. Esperaba que las herramientas de diferenciación pudieran hacer frente si faltaban.

— pgfearo

1

Algunas herramientas de control de versiones y diff ofrecen la opción de ignorar las diferencias de espacios en blanco.

— FrustratedWithFormsDesigner

1

+1 - No puedo ver ningún beneficio en esto, todo lo que va a hacer es desordenar el control de versiones y las herramientas diff.

44

@pgfearo El problema que tengo con algo como esto es que sería casi genial, pero el <1% de los cambios que no quiero hacer es que el editor siga adelante y los cambios de todos modos serían enloquecedores . Su editor tendría que ser completamente personalizable hasta el enésimo grado para garantizar que satisfaga las necesidades de todos.

— Michael Todd

1

@pgfearo - formato xml, sí, este es definitivamente el enfoque a seguir, pero pensé que así era como la mayoría de los editores formatearon xml de todos modos.

4

Eso seria genial. Emacs hace más o menos esto, y en su mayoría lo hace bien. ¿Has probado el modo nXML de Emacs? ¿Cómo mejorarías en eso?

No puede crear un nuevo editor hasta que haya probado lo que ya está disponible.

De todos modos, la sangría debe guardarse en el archivo de salida, para que el archivo se pueda ver con otras herramientas. No es probable que adopte un nuevo editor a menos que admita la personalización en tiempo de ejecución como Emacs.

— Kevin Cline
fuente

¿Por qué se debe guardar la sangría? ¿Deberíamos imponer nuestro formato a los demás? ¿La gente todavía usa herramientas que no tienen complementos XML disponibles, que pueden formatear el XML según sus necesidades (no las del autor)?

— pgfearo

En Emacs Solo he usado Emacs el tiempo suficiente para saber que no tuve el tiempo (entonces) para aprenderlo adecuadamente para hacerle justicia. Sospecho que los usuarios de Emacs se verían igualmente presionados para intentar 'la otra manera'. Volveré a mirar Emacs nuevamente, pero me preocupa el "en su mayoría lo hace bien", puede mejorar eso.

— pgfearo

@pgfearo se llamacat

— alternativa

@mathepic con suerte * ¿los desarrolladores de línea de comandos de nix tienen acceso a xmlsh o algo similar?

— pgfearo

@pgfearo Honestamente, nunca había oído hablar de eso y nunca usaría un shell para xml;)

— alternativa

3

He visto esta idea antes, pero nunca la he visto funcionar. La mayoría de las veces, cuando he visto la idea de llegar, ha sido derribado por todos los desarrolladores por ahí - o cuando se ha puesto en práctica, lo que hizo que el control de versiones prácticamente inútil como una simple visualización de código de plegado cambiaría el archivo y más confunden La herramienta diff. (Un ejemplo de lo malo que es esto es el Witango Development Studio).

Puedo pensar en varios obstáculos que su editor tendría que superar para ser útil para muchos desarrolladores:

Los cambios en un archivo no deben crear ruido en el diff -uwcomando * nix . (¡Sin diferencias espurias!)
La edición de un archivo (previamente sin formato) no debe complicar las fusiones en las herramientas SCM.
Debe jugar muy bien con otros editores utilizados por el equipo de desarrollo.
Los usuarios deben poder personalizar el formato al contenido de sus corazones; a algunas personas les apasiona cómo aparece su código.
Las ediciones al código existente no deben cambiar el formato existente. Es crucial que el editor no vuelva a formatear repentinamente un archivo completo sin razón aparente y no cambie el formato de una línea para simples ediciones menores, eso confundirá las herramientas diff y enojará a otros miembros del equipo.
Probablemente no debería eliminar el espacio en blanco en exceso, probablemente molestará a alguien . Mejor no arriesgarse.
Las nuevas líneas agregadas a un archivo deben cumplir con la configuración de las modelinas existentes, o deben cumplir con el formato existente local (dentro de +/- 3 líneas).
El editor debe tener un panel de configuración que permita al usuario definir la política de formato de código del equipo que es independiente de lo que el editor realmente muestra.

No es necesario decir que es obvio que esto requerirá cierta cantidad de metadatos sobre el formato existente del archivo. Es probable que desee mantenerlo separado de las fuentes, pero mantenerlo sincronizado con un repositorio en constante cambio probablemente sea bastante difícil.

Como usuario de Vim, también opino que el editor debe respetar las modelos de Vim, Emacs y otros editores y preservar el formato proscrito de la línea de modelado, independientemente de lo que finalmente muestre.

En mi opinión, los requisitos para dicho software lo hacen insostenible. Demasiados usuarios esperarán demasiado de él con demasiada frecuencia para que un proyecto de este tipo tenga éxito.

— Greyfade
fuente

Parece que estamos atascados con nuestra solución actual, no porque sea la mejor, sino porque es demasiado difícil de cambiar. Lamentablemente, esto es cierto en tantas áreas de TI que sería tonto / arrogante para mí sentir que podría solucionarlo por mi cuenta. Como soy un poco obstinado, seguiré utilizando este concepto integrado como una herramienta opcional en una solución de escritorio mucho más grande donde el procesamiento / análisis es la principal preocupación. De esa manera, el desarrollador tiene una opción.

— pgfearo

@pgfearo: No, creo que estamos "atrapados" en nuestra situación actual, no porque sea lo mejor, sino porque no hay nada mejor. Para convencer a los usuarios de Vim y Emacs de la idea, deberá proporcionar un beneficio sustancial sobre las herramientas ya eficientes que usan. Para ganarse a todos los demás, solo necesitará proporcionar las características que los usuarios de Vim y Emacs ya disfrutan para un público más amplio. Espera, tal vez eso licencia TextMate es digno de él.

— greyfade

@pgfearo: Mi punto general es que no creo que puedas lograr algo que alguien quiera usar sobre sus herramientas existentes, excepto por un subconjunto muy pequeño del trabajo que hacemos. Hay un beneficio obvio para los hackers XML y XSLT, ya que la estructura es el 99% del trabajo, pero hay muchos menos beneficios obvios para lenguajes menos estrictamente estructurados como C, Java, C #, Ruby, etc. Esto es muy difícil de vender. -núcleo.

— greyfade

Sí, este punto sobre herramientas / métodos existentes eficientes es el número 1 en las conclusiones editadas (provisionales) de la pregunta. Por lo que ya se ha dicho, dudo que incluso deba intentar conquistar a los usuarios de Vim / Emacs; si alguna vez hay interés en esto, vendrá de otro lado.

— pgfearo

Aceptó esta respuesta porque desglosa los problemas de manera sucinta y está en línea con el sentimiento general de otras respuestas / comentarios. No era la respuesta que esperaba, pero me ayudó a persuadirme de que, al menos para entornos que no son XML / XSLT, no tiene sentido seguir con este concepto, no hay necesidad de desperdiciar más esfuerzo.

— pgfearo

2

Solución, utilizando archivos de configuración de formateador basados en texto (por ejemplo, XML):

Tener un formateador personal configurado por el desarrollador individual.
- Almacene este formateador localmente.
- Los archivos se cargan y editan con formato local.
- Pueden cambiar libremente su estilo de formato sin romper nada.
- El formateo automático se puede desactivar para mostrar y editar archivos sin formato.
Tener un formateador de equipo mínimo configurado para el estándar del equipo.
- Almacene este formateador en el control de versiones del equipo.
- Los archivos se guardan con formato de equipo como alternativa para otras herramientas.
- Las diferencias no sufren problemas de formato.

Es ridículo preocuparse por la economía de guardar archivos sin espacios en blanco extraños, por lo que en realidad no pierde nada al guardar los archivos con un formato definido por un estándar del equipo. En el caso de un desarrollador en solitario, podría ofrecer la posibilidad de tener el formato de visualización en espejo (para el "equipo" de uno).

Cuando el formateador es insuficiente, tiene dos opciones viables:

Exponer una interfaz para formateadores personalizados.
- Bien hecho, esta es la mejor solución.
- Hecho mal, es lo peor.
Permitir anulación manual de formato automático.
- La usabilidad no sufre: considere Ctrl- (Enter | Tab | Space).
- La cordura sí, ¿dónde guarda este formato? ¿Vos si?

— Jon Purdy
fuente

Puntos utiles. Me gusta la idea de haber compartido archivos de configuración del formateador. El formateo automático ya es conmutable en el prototipo, porque es esencial para aislar el espacio en blanco 'real' del material virtual. Cambiar entre vistas, por supuesto, no altera un solo personaje. Mi inclinación no es proporcionar una opción dentro de la herramienta para guardar 'con formato', sino proporcionar 'adaptadores' que sean gratuitos, multiplataforma y que también puedan ejecutarse como un servicio web, estos podrían usar los mismos archivos de configuración de formateador XML tu sugieres.

— pgfearo

2

Estaría de acuerdo con que el código se formatee automáticamente si el lenguaje no fuera sensible al formato tos Python tos .

Emacs hace que el formateo de Lisp sea realmente agradable, y se formateó sobre la marcha, estaría muy feliz. No soporto la inserción automática de parens u otros delimitadores: ninguno de los autoinsertadores que he intentado lo acerca a la forma correcta de cómo escribo.

— Paul Nathan
fuente

Sí, creo que F # también usa el formato dentro de su sintaxis. La inserción automática de delimitadores es un problema. Para XML, esto toma la forma de agregar comillas, etc. No es perfecto, pero compensa a los mecanógrafos que posiblemente estén por delante de la carrera, por lo que verifica que algo que está escrito no haya sido puesto en cola para la inserción automática. de todos modos, evitando la repetición. Sin la inserción automática, el analizador se queda adivinando cómo sangrar: puede retrasarse un poco, pero se produciría una `` sacudida '' del margen a medida que el analizador intenta comprender la verdadera intención del código que se está escribiendo.

— pgfearo

@pgfearo: fortran, cobol, f #, haskell, python, make y algunos otros sistemas están delimitados por espacios en blanco. Es bastante IMO ridículo, ya que dificulta las herramientas automáticas en su funcionamiento (y el análisis del usuario), pero, ya sabes, estamos atrapados con ellos.

— Paul Nathan

2

Me encanta la idea en concepto . Y aunque puede tener éxito, todavía tengo que encontrar un editor que haga lo suficiente todo lo que quiero que haga en términos de formato. Aquí hay algunos obstáculos (IMO):

Lenguajes exigentes con espacios en blanco
¿Qué se guarda en la salida? (Debería, hasta cierto punto, guardar al menos parte de la sangría para que pueda leerse a otros sin la herramienta)
Debe ser absolutamente agradable con los productos existentes de control de fuente / control de versiones ya existentes
Debe ser altamente personalizable, especialmente para aquellos de nosotros (incluido yo) que somos muy, muy quisquillosos sobre cómo se formatea y sangra el código (y dónde debe ir esa coma en una lista, pero si la lista es realmente larga, cómo las líneas deben estar rotas, etc.)
Realmente debe entender el idioma. Con esto quiero decir que debe seguir el lenguaje exactamente como el compilador lo entenderá. He tenido demasiados editores con sintaxis de colores que se equivocan con la sintaxis porque hay una faceta chiflada del lenguaje que no se puede manejar simplemente con un RegExp. De acuerdo, usted indicó que analizaría continuamente el idioma, pero ¿quién puede decir que lo que analiza se ajusta al compilador que estoy usando? (Créame, hay muchos estándares por ahí, y hay muchos negocios divertidos que se llevan a cabo en la mayoría de los idiomas, incluido el código que parece incorrecto para un analizador simple, pero es perfectamente correcto para el compilador).
Debe ser rapido . Y aquí es donde el caucho se encuentra con el camino: no puede realizar una ejecución de compilación completa en mi código cada vez que se presiona una tecla (especialmente con un proyecto grande), a menos que pueda optimizar su analizador al enésimo grado. Si incluso hay un toque de lentitud en el editor, nadie lo usará. (Soy un ejemplo perfecto de abandono de editores lentos en favor de los más rápidos. Si se retrasa lo más mínimo, estoy fuera).

¿Podría crear algo que cumpla con la mayoría de los criterios razonablemente bien? Probablemente. Pero nosotros, los programadores, somos quisquillosos, quisquillosos y detestamos cambiar, y saltaremos a la primera señal de problemas. Aquí su problema será si la salida marca a alguien más en el equipo de desarrollo, o si no funciona 100% bien con el sistema de versiones, o si no formatea mi código exactamente o si malinterpreta el idioma y sangra mal mi código, o si se retrasa un milisegundo más de lo que esperaba. Porque, por mucho que me guste la idea, saltaré a mis editores preferidos en un instante.

— Kerri Shotts
fuente

En su punto de rendimiento: la capacidad de respuesta puede ser comparable a las herramientas existentes. Debido a que el formateo no tiene efecto en el texto del código, el procesamiento se puede ejecutar en segundo plano y finalizar a voluntad. Con XSLT, hay un enfoque en cascada, el formateo / coloración se realiza antes de la validación de grano fino y la compilación final. Como todo esto sucede en un subproceso de fondo y se interrumpe inmediatamente en la siguiente pulsación de tecla, no hay un retraso de rendimiento perceptible. Solo el texto visible necesita actualizarse inmediatamente, el texto restante se formatea de nuevo en ráfagas fragmentadas cuando hay una pausa.

— pgfearo

¿Qué se guarda en la salida? Sin formato directamente, ya que esto impondría un estilo de formato a otros. La idea (en respuesta a las respuestas anteriores) es proporcionar formateadores conectables que usen un archivo de configuración estándar que declare las reglas de formato y la salida en consecuencia, bajo demanda.

— pgfearo

1

Existe un enfoque aún más radical: un editor semántico puro. Un IDE trata con un código que incluso se representa internamente como un AST, no como un texto plano. Ver JetBrains MPS por ejemplo.

— SK-logic
fuente

Esto es interesante. Todavía no entiendo completamente el enfoque de MPS, pero el diseño de este editor utiliza un AST equivalente a los mapas a las posiciones en el texto plano XML. Entonces, siempre que haya interacción del usuario con el texto plano, el editor sabe de inmediato qué parte del 'AST' se está editando. Esto lo ayuda a determinar si es necesario realizar un análisis, y también ayuda a proteger partes del árbol de la eliminación involuntaria, cuando el usuario realiza la eliminación "presionar y mantener", por ejemplo. Esto también se utiliza para presentar datos sobre la selección actual en tiempo real. Voy a mirar más a MPS.

— pgfearo

0

Ahora que he publicado el editor XML descrito en mi pregunta, estoy en una posición mejor (pero no ideal) para intentar responder esto yo mismo, así que haré lo siguiente:

Después de más de 500 descargas en menos de 2 semanas, la reacción a este nuevo concepto innovador en formato de código dinámico ha sido ...

NULO

Sin quejas, sin elogios. Mi interpretación (esperanzada) de esto es que la gente solo quiere y espera un editor que se sienta normal y no estropee su código. Los usuarios apenas notarán que su formato es completamente virtual y la evidencia sugiere que les importa aún menos.

Sin embargo, sería un error leer demasiado sobre esta no reacción, esta herramienta es gratuita y, desafortunadamente, esto significa que al menos algunos usuarios estarán menos inclinados a criticar. Si no les gustó, pueden haberlo descartado y haber usado otra cosa.

— pgfearo
fuente