Estaba leyendo Code Complete y en el capítulo sobre diseño y estilo, él estaba prediciendo que los editores de código usarían algún tipo de formato de texto enriquecido. Eso significa que, en lugar de que el código se vea así

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

podría verse así:

Procedimiento ResolveCollisions

Realiza una resolución de colisión a posteriori a través del algoritmo de partición espacial

Parámetros

• CurrentMap : SpriteContext
• PotentialColliders : SpriteList

Variables locales

• Collider : Sprite
• Collidee : Sprite
• Collision : SpriteCollision

    DoStuff();

He visto coloreado y resaltado de sintaxis e incluso paréntesis para colorear, pero nada parecido a esto en el código real. Me preguntaba si este tipo de cosas realmente existió alguna vez, o tal vez si se decidió que no tenía suficiente beneficio o que era una idea completamente mala.

¿Alguno de ustedes ha visto código con formato rico como este antes, o sabe si la idea alguna vez fue considerada y finalmente rechazada?

No hay ninguna razón técnica por la que no puedas. Si los editores de texto pueden resaltar la sintaxis, podrían cambiar fácilmente otros aspectos de la pantalla para resaltar el código.

Sin embargo, una cosa es que todo lo que se está escribiendo se cambie de color a medida que el editor descubre lo que está escribiendo. Hacer que el texto cambie repentinamente de tamaño y salte mientras escribes sería realmente desagradable.

Sin embargo, para una visualización de código 'estático', puede embellecer fácilmente el código fuente. Por ejemplo, tome cualquier convertidor de fuente-> html decente y agregue los tamaños y estilos de fuente que desee a las hojas de estilo, y tendrá un código con formato enriquecido.

Razón simple: editor / herramienta de independencia.

Una vez que haga que su código sea "enriquecido", estará vinculado al editor que utilizó o a los que puedan entender el código enriquecido. Todos los demás editores que no pueden manejar la riqueza mostrarán galimatías.

En el mismo sentido, el código enriquecido no funcionaría bien con las herramientas diff. Por ejemplo, si acaba de cambiar algo de formato, la diferencia mostrará una diferencia, pero ni siquiera es una diferencia que le preocupe menos.

¿Y qué hay del control de versiones? ¿Cómo le dirías que ignore todos los cambios en el formato y vea los archivos como modificados solo cuando hay algún cambio "real"?

Finalmente, supongo que todo el punto del código enriquecido es la legibilidad, y para eso, creo que serán mejores comentarios (y más), nombres de identificadores lógicos y sangría consistente.

En esencia, el texto de programación se maneja mejor como un texto simple: lo que está viendo es cuál es la realidad. ( que también está en línea con la idea pitónica de explícito mejor que implícito )

Quizás el código con formato enriquecido no se ha dado cuenta porque no es una idea tan genial. Personalmente, no me gusta lo que veo en el ejemplo que proporcionó. Utilizo el color y el resaltado de sintaxis, pero ese formato es demasiado forjado y se desvía demasiado de la forma en que estoy acostumbrado a ver y escribir código.

¿Por qué no existe? No existe la demanda / necesidad de ello.

Los editores actuales pueden satisfacer las necesidades de los programadores con resaltado de sintaxis y algunas otras opciones estilísticas menores. ¿Ya no es "texto enriquecido"?

Esto ya existe para LaTeX en modo AucTeX para Emacs. Los títulos de las secciones son de mayor tamaño, los subíndices y los superíndices se redimensionan adecuadamente e incluso puede tener pequeñas vistas previas de matemáticas (y posiblemente otros entornos como Algorithmic).

Esto está bien para LaTeX porque la asignación del código a la salida suele ser mucho más sencilla que en otros programas; Creo que no me gustaría eso en absoluto para los idiomas más generales.

Otra cosa que Emacs puede hacer es reemplazar símbolos como ->y forallcon →y ∀respectivamente en Haskell. Hay pocas razones por las que este tipo de cosas no pueden extenderse a formatear como sugiere, excepto que no es necesario en Haskell.

Hace algún tiempo, hice esta pregunta sobre el formato del código, preguntando si los programadores querrían que su código se formateara mientras escribían.

Mi pregunta solo abordó el aspecto de sangría del formato, pero algunas respuestas pueden aplicarse al formato de código en general. El sentimiento general en las respuestas sugiere que los programadores se oponen a perder el control absoluto de la forma en que se representa su código.

Mi experiencia personal ha sido bastante diferente. Aunque normalmente uso herramientas disponibles públicamente, a veces necesito escribir XSLT en mi propio editor a medida. Este editor formatea el código a medida que escribo al sangrar el margen izquierdo para que no tenga problemas con los espacios en blanco no deseados (significativo en XSLT) y permite que mi código se ajuste a las palabras y aún así mantenga el formato. Creo que la experiencia es bastante natural, el estilo de formato está controlado por el contexto y la posición de los avances de línea por sí solos (la experiencia es especialmente gratificante cuando se utilizan dispositivos de entrada sensibles al tacto).

Si el XSLT no está bien equilibrado, el formato realmente ayuda a mostrar dónde radica el problema. Me tomó un tiempo ajustar el cambio de código horizontalmente mientras escribes, pero ya no es una distracción para mí. Sin embargo, descubrí que las características de formato que afectaban el espaciado vertical de mi XSLT dejaban el editor prácticamente inutilizable, así que las desactivé.

Para volver a su pregunta, creo que la razón por la cual el formato de código enriquecido no es más común es que las percepciones tardan mucho en cambiar en el mundo de la programación. Llegará su momento, posiblemente coincidiendo con el momento en que la edición de código se realiza predominantemente sin un teclado.

También en más de unos pocos idiomas (Haskell, Ruby, Python, Erlang, CoffeeScript, algunos otros) la sangría es importante. Entonces, si está cambiando los tamaños de fuente, podría ser muy difícil de entender.

Sobre todo su tradición. He estado programando profesionalmente durante casi 20 años y sospecho que me volvería loco. Escribo libros en Emacs o VI con docbook, así que no soy fanático de WYSIWIG

Knuth's CWEB hace esto, pero solo funciona para C / C ++ y Pascal. - Sin embargo, deberías echarle un vistazo ... está bastante bien. Hay dos programas: ctangley cweaveque combinan / separan archivos CWEB en TeX y C respectivamente.

¿Alguno de ustedes ha visto código con formato rico como este antes, o sabe si la idea alguna vez fue considerada y finalmente rechazada?

Seguro. Xcode admite estilos más allá de la simple coloración para diferentes sintaxis:

Ha pasado mucho tiempo desde que lo usé, pero creo que Metrowerks CodeWarrior también admite texto con estilo, y eso fue hace más de 10 años.

Sin embargo, no desea exagerar con los estilos: cualquier texto, código fuente o de otro tipo puede ser más difícil de leer cuando los estilos varían demasiado. En particular, creo que mezclar tamaños es una distracción, y cualquier cosa que haga que las columnas no se alineen es molesto. Hay una razón por la que la mayoría de los programadores todavía usan fuentes monoespaciadas.

Una pregunta diferente es si el texto con estilo debe usarse como parte de la sintaxis del lenguaje. Por ejemplo, ¿debería el compilador utilizar el hecho de que parte del texto tiene un estilo determinado para determinar que el texto es una declaración de función? Al principio puede parecer una locura, pero lenguajes como Python y Fortran ya usan sangría como sintaxis. Sin embargo, creo que es más probable que sigamos viendo el estilo impulsado por la sintaxis en lugar de al revés. Hay muchos beneficios que resultan de poder usar texto sin formato (compiladores más simples, independencia de plataforma, preferencias del programador), y otras tradiciones han evolucionado para hacer que el código sea legible en ausencia de estilos (sangría, líneas en blanco, caracteres de marcador y características del editor como plegado de código y menús de navegación).

Creo que el formato enriquecido del código fuente no es muy popular porque está destinado a la entrada de información, donde la estructura y el significado son mucho más importantes (y también más fáciles de escribir). La fuente, los símbolos extra especiales y los espacios en blanco solo agregan ruido visual innecesario. Sin embargo, podría ser apropiado para la documentación generada.

Nunca hay una guerra de llamas sobre el mismo tema en el mundo de la composición tipográfica entre aquellos que prefieren editores WYSIWYG (como MS Word) y sistemas como TeX (LaTeX).

En general, no hay una respuesta definitiva. Todo depende de herramientas, casos de uso y preferencias personales.

Herramientas como Doxygen o JavaDoc ya realizan el formato de código de texto enriquecido. Añaden hipertexto de código también para fines de navegación. No necesita insertar etiquetas especiales para el formateo básico.

Sin embargo, esto no es WYSIWYG.

Tengo miedo de decir que esto existe.

En el pasado, he trabajado en algún código Centura (también conocido como Gupta o SQL / Windows, un antiguo código " 4GL "). Realmente no era posible editar el código Centura en un editor estándar como el bloc de notas para el nivel extremo de formato requerido.

Aunque puede parecer una buena idea tener un archivo fuente formateado de esta manera, descubrí que el desarrollo es bastante restrictivo y doloroso.

Además, el formato a menudo causaba problemas al fusionarse en el control de origen.

Además de las otras respuestas, me gustaría señalar que, además de las dificultades técnicas de utilizar el formato enriquecido, también es objeto de preferencia personal.

Si edita texto plano, puede elegir las fuentes y colores que desee, y se configuran automáticamente. Si edita texto enriquecido, ¿qué sucede si simplemente no le gustan los colores y las fuentes particulares que se configuran manualmente?

Creo que esto se debe a que todavía nadie separó la lectura de código y la escritura de código. Al menos no se convierte en la corriente principal. A veces tienes que leer el código que tocaste hace mucho tiempo o el código creado por otros desarrolladores. Probablemente tendrá que pasar mucho tiempo hasta que esté listo para cambiar un solo byte en esta fuente. Este podría ser el modo de "lectura" que puede hacer lo que sea necesario para una comprensión más fácil (tamaño de fuente, reformateo, sub-script, super-script, etc.). Cuando esté listo, el editor puede cambiar al modo de "escritura" y ser menos restrictivo y más obediente a "la regla de la menor sorpresa"