Esta semana, Chris Ferdinandi examinó un fragmento de JavaScript inteligente, uno que está escrito de manera creativa con nuevas características de sintaxis, pero que quizás sea menos legible y de mejor rendimiento. Es una lectura rápida, pero su llamado a la fijación de nuestra industria en la inteligencia vale la pena… llamar:
…nos hemos obsesionado como industria con la brevedad y el código inteligente, y el resultado es un código que a veces tiene menos rendimiento y, por lo general, es más difícil de leer y entender para la mayoría de las personas.
Hizo un argumento similar a fines del mes pasado cuando escribió sobre la legibilidad del código, y señaló que la brevedad puede parecer genial, pero en última instancia conduce a todo tipo de problemas en una base de código:
A menudo, los desarrolladores web están obsesionados con la brevedad. Existe esta cosa donde los desarrolladores intentarán escribir la misma función en la menor cantidad de caracteres posible.
Personalmente, creo que la brevedad no tiene sentido. La legibilidad es mucho más importante.
Estoy completamente de acuerdo con Chris en este punto, sin embargo, creo que hay una distinción importante que hacer y esa es la diferencia entre el código que pretende ser un prototipo y el código que está destinado a la producción. Como argumentó Jeremy Keith hace un rato:
Lo interesante es que, cuando se trata de creación de prototipos, nuestras prioridades habituales de front-end pueden y deben desaparecer. La prioridad ahora es la velocidad. Si eso significa sacrificar la semántica o el rendimiento, que así sea. Si estoy construyendo un prototipo y me encuentro pensando “ahora, ¿cuál es el nombre de clase correcto para este componente?”, entonces sé que tengo la mentalidad equivocada. Esa pregunta puede ser válida para el código de producción, pero es una pérdida de tiempo para los prototipos.
Estoy de acuerdo con Chris en que deberíamos escribir código que sea fácil de leer cuando estamos en producción. También creo que experimentar con el código de esta manera es algo bueno cuando se trata de prototipos. Nunca deberíamos rehuir jugar con el código y empujar las cosas un poco, siempre y cuando no lo hagamos en una aplicación web gigante con un equipo de otros desarrolladores trabajando junto a nosotros.
He notado que hay algunas personas que están haciendo cosas genuinamente ingeniosas con Sass. Constantemente me siento y pienso: “Vaya, nunca antes había visto algo así”. Pero cuando se trata de una aplicación web de producción que tiene que ser entendida por cientos de personas al mismo tiempo, no creo que esta sea la reacción que queremos cuando alguien mira el código.
Como resultado, he estado tratando de escribir código Sass que en realidad es tan simple que casi parece tonto. Una manera fácil de hacer que el código sea mucho más simple es reducir la cantidad de anidamiento:
.element {
.heading { ... }
}Esto se ve bien cuando hay código dentro, y es bastante fácil de entender, pero agrega un poco de diseño complejo a la mezcla (por ejemplo, usando pseudo elementos y consultas de medios) y de repente tienes un conjunto bastante complejo de reglas frente a ti. La creatividad y la inteligencia pueden ser más difíciles de escanear e identificar una pequeña parte del código que está buscando. Además, en este ejemplo, hemos hecho innecesariamente nuestro .heading clase un poco más específica, lo que podría alentarnos a anular las cosas de una manera pirateada en otras partes de la base de código.
Podríamos escribir lo siguiente:
.element { ... }
.element-heading { ... }Sé que esto parece tontamente simple, pero la relación entre estas dos clases es más fácil de ver y extender en el futuro. Agrupar todo ese código en una sola clase anidada puede salirse de control muy rápido. Incluso si se ve mucho más genial.
(Aparte, la publicación de Andy Bell sobre el uso del ampersand en Sass, y los comentarios resultantes, es un gran ejemplo del choque entre la creatividad y la practicidad).
De todos modos, el punto que estoy tratando de hacer aquí es que CSS (y JavaScript para el caso) es un lenguaje extraño porque no hay reglas definidas que puedas hacer al respecto. Realmente todo depende del código base y del proyecto. Pero creo que podemos decir con seguridad que nuestro código debería ser mucho más aburrido que nuestros prototipos cuando pase a producción.
¡Sigue haciendo prototipos que sean salvajes y experimentales o increíblemente extraños! Maldita sea la calidad del código.