Cómo resaltar el código según lo que realmente importa
Highlighting My Code Based on How Much I Care
Inspirado en un artículo de Nikita Prokopov sobre los fallos del resaltado de sintaxis, el autor abandona los temas de color y experimenta con un enfoque en escala de grises. Tras descubrir que los temas claros son difíciles de diseñar y que el color puede distraer, propone un sistema que prioriza comentarios, definiciones y flujo de control, mientras minimiza palabras clave y puntuación. El resultado es un resaltado que ayuda a escanear el código rápidamente y a centrarse en lo semántico.
El resaltado debería permitir que tus ojos salten entre las partes que más importan al leer, para que puedas centrarte en las partes semánticas y pasar por alto lo puramente sintáctico.
- nrabulinski
> intenta recordar qué color usa tu tema de color para los nombres de clase.
Aunque en general estoy de acuerdo con el punto de esta publicación y la publicación citada, no estoy de acuerdo con la premisa de que necesitas poder recordar activamente hechos como este. El tema que uso personalmente es bastante sobrio, pero sí usa colores diferentes para variables, palabras clave, argumentos, nombres de tipos y algunas otras clases de tokens. No pienso conscientemente "mmm, ¿de qué color es un argumento?" para buscar esos en mi código; simplemente los veo, los he aprendido a lo largo de los años, y es memoria muscular a estas alturas, y me ayuda a leer el código. Así como no puedo recordar el código de mi edificio de apartamentos, y sin embargo lo escribo varias veces al día.
- sph
Estoy convencido de que todos se equivocan con el resaltado de sintaxis y este artículo me respalda.
Mis quejas favoritas:
- No tengo idea de cómo se supone que la gente sea productiva con temas de vómito arcoíris no semánticos que son tan populares en los editores modernos. Soy demasiado TDAH como para querer estar sobreestimulado por información inútil.
- Rutinariamente odio encontrarme con código Zig en Github, donde el tema que usan vuelve todo marrón. Oh, es porque es un miembro de struct. Amigo, todo es un miembro de struct en Zig, es tonto asignar un color vibrante a lo que equivale al 90% del código fuente. Ejemplo aleatorio de mi historial del navegador: https://github.com/foxnne/aftersun/blob/main/src/time/enviro...
- Ayer abrí algo de código Lisp en el editor de texto KWrite de KDE, y cada tema predeterminado resalta los paréntesis con una fuente en negrita y un color vibrante para que destaquen. Se supone que los paréntesis en Lisp deben desvanecerse en el fondo, no saltarte a la cara. Era completamente inutilizable, tuve que desactivar el resaltado de sintaxis.
Siempre buscando temas de color mínimos, apagados y buenos para mis editores. Ojalá tuviéramos diseñadores serios que diseñaran temas para la usabilidad y la comodidad, y no personas que no tienen nada que ver con jugar con colores.
Recuerdo a un colega que solía escribir código con el resaltado de sintaxis desactivado, y pensaba que era una elección excéntrica. Cuanto más envejezco, más aprecio su sabiduría. Prefiero no tener resaltado de sintaxis que uno malo; al menos uno intentaría hacer que el código sea fácil de analizar solo por su estructura (cortado...)
- wzdd
Estas publicaciones de replantear el resaltado siempre comienzan con una premisa equivocada. El color de los nombres de clase en mi código es el color que tienen todos los nombres de clase. Después de poco tiempo trabajando con el código, notaría si uno se veía raro.
El cerebro es realmente muy eficiente. No optimizas para recordar cosas fuera de contexto a menos que realmente te esfuerces. No dice nada sobre la eficacia del esquema.
- mattlondon
Mmm, esto no era lo que esperaba.
Pensé que podría ser algún tipo de resaltado basado en complejidad/riesgo/importancia. Eso inmediatamente me pareció un momento de "¿por qué no pensé en eso?" cuando en realidad resulta que tampoco lo hicieron.
Así que puedo imaginar un escenario donde tienes el diff de un agente LLM para revisar mientras iteras en un IDE. El diff se resaltaría según la importancia/complejidad para la revisión humana. Trivialidades como getters y setters estarían en gris. El código altamente complejo, complicado o arriesgado se resaltaría en algún color audaz de alto contraste (quizás con una escala de luminancia dependiendo de cuán crítico fuera). Entonces, cuando revisas el diff del agente, puedes ver y enfocarte instantáneamente en las partes más importantes que necesitan más atención.
Eso me parecería realmente útil.
- rfgplk
Me gusta el estilo del blog, pero la fuente es realmente difícil para los ojos.