El diseño del código sí importa
Autor: Steve Freeman
Hace muchos años trabajaba en un sistema en Cobol, en el cual no se le
permitía al personal cambiar la sangría a menos que tuvieran una razón
para cambiar el código, debido a que alguien, alguna vez, descompuso
algo al dejar un trozo de línea en una de las columnas especiales al
inicio de una línea. Esto aplicaba incluso si el diseño estaba
equivocado, lo cual sucedía algunas veces, así que teníamos que leer el
código muy cuidadosamente porque no podíamos confiar en él. La política
debió costar una fortuna en fricción de programador.
Hay una investigación que muestra que todos pasamos más de nuestro
tiempo de programación navegando y leyendo código –encontrando dónde
hacer el cambio– que escribiendo, así que esto es lo que queremos
optimizar.
- Fácil de escanear. La gente es buena en la comparación de patrones
visuales (una reminiscencia de la época en la que teníamos que observar
leones en la sabana), así que puedo ayudarme al hacer todo lo que no es
directamente relevante al dominio, toda la “complejidad accidental” que
viene con muchos lenguajes comerciales, ocultarlo en el fondo de
pantalla para estandarizarlo. Si el código que se comporta igual luce
igual, entonces mi sistema perceptual me ayudará a escoger las
diferencias. Es por eso que también observo las convenciones sobre cómo
diseñar las partes de una clase dentro de una unidad de compilación:
constantes, campos, métodos públicos, métodos privados.
- Diseño expresivo. Todos hemos aprendido que toma su tiempo encontrar los
nombres adecuados para que nuestro código exprese, tan claramente como
es posible, lo que hace; en lugar de sólo listar los pasos, ¿está bien?
El diseño de código también es parte de esta expresividad. Un primer
corte es tener el acuerdo del equipo en un formateo automático para lo
básico, entonces podemos hacer ajustes manuales mientras estamos
codificando. A menos que haya un disensión activa, el equipo convergerá
rápidamente en un estilo de “acabado manual” común. Un formateador no
puede entender mis intenciones (debería saberlo, una vez codifiqué uno),
y es más importante para mí que los saltos de línea y los agrupadores
reflejen la intención de mi código, no sólo la sintaxis del lenguaje
(Ken McGuire me liberó de mi esclavitud a los formateadores automáticos
de código).
- Formato compacto. Mientras más puedo conseguir en una pantalla, más
puedo ver si se rompe el contexto al desplazarme o al cambiar de
archivo, lo que significa que puedo dejar menos estados en mi cabeza.
Los comentarios del procedimiento largos y los espacios en blanco tienen
sentido para nombres de 8 caracteres e impresoras, pero ahora vivo en un
IDE que hace el coloreo de sintaxis y el enlace cruzado. Los pixeles son
mi factor limitante, así que quiero que cada uno contribuya hacia mi
entendimiento del código. Quiero que el diseño me ayude a entender el
código, pero no más que eso.
Un amigo no programador comentó alguna vez que el código se parece a la
poesía. Tengo esa sensación en el código bueno, que todo en el texto
tiene un propósito y está ahí para ayudarme a entender la idea.
Desafortunadamente, escribir código no tiene la misma imagen romántica
que escribir poesía.
Traducción: Espartaco Palma
Leer contribución original