Necesitamos hablar acerca del código en una-línea

Bueno no. A menudo no es mejor escribir un código más corto. ¿Fin de la entrada del blog?

Bueno… otra vez no. Creo que requiere un poco de aclaración. ¿Por qué el impulso del código corto y por qué es malo? O mejor aún, ¿por qué un código más corto puede ser malo? Y digo puede porque un código más largo puede ser problemático. Se trata de la calidad del código.

Echemos un vistazo a una declaración `if-else` simple

if (numberOfThings > 5) {
	proceed();
} else {
	showError();
}

Esto es muy claro, ¿verdad? Fácil de leer, fácil de seguir, fluye bien. A menudo, este tipo de código se reemplaza con algo como esto

numberOfThings > 5 ? proceed() : showError();

O tal vez esto

(numberOfThings > 5 ? proceed : showError)();

La funcionalidad es idéntica, pero es de una sola línea. Es más corto, pero ¿es mejor? En situaciones simples, como la ilustrada arriba, podría ser mejor pero ya es más difícil de leer. En lugar de 1 segundo, puede tomar 2 para leer el código, más si no está muy familiarizado con la instrucción if-else abreviada.

Todavía solo estamos tratando con 2 llamadas de función, por lo que esto podría no ser tan malo, pero si se incluye entre otras 100 líneas que también hacen que todo sea más corto, ¿será mejor?

Pero, ¿qué pasa si las funciones a las que llama son cortas en sí mismas y decide omitir las funciones y simplemente llevar la lógica al if-else? Entonces estamos obteniendo algo más horrible.

numberOfThings > 5 ? $.form.submit() : $.errormessage.text = “error message”;
$.errormessage.show();

Así que ahora ya no cabe en una línea en Medium. Todavía es un código simple, pero ¿prefieres ver esto? ¿O prefiere las llamadas a funciones que tienen su propia funcionalidad?

Las cosas empeoran cuando una frase como esta comienza a devolver valores, cuando se está produciendo una transformación de datos o todo lo anterior a la vez. He visto algunas frases ingeniosas bastante malas que eran un código "bueno" porque son cortas y compactas.

Es hora de recuperar la estructura y reintroducir un código más largo para el beneficio de la lectura. Después de todo, los humanos se preocupan por la estructura, el navegador o su servidor no tienen en cuenta la estructura, o se preocupan mucho si el código es más largo.

Para la interfaz, tenemos minificación para encargarnos de acortar las cosas, y para muchas situaciones, tienes compiladores que lo convierten en algo más de todos modos. En muchos entornos de producción, es increíblemente raro que el código que ha escrito termine en el dispositivo que ejecuta el código exactamente de la misma forma.

Entonces, ¿por qué tanta presión por las frases ingeniosas perfectas?

¡Deberíamos centrarnos en la legibilidad!

Todo lo que importa en el código de producción es la legibilidad. Realmente, ese es el aspecto más importante de escribir código, especialmente si estás trabajando en equipo.

Claro, usted puede ser el desarrollador senior que conoce literalmente todos los entresijos del lenguaje, pero ¿realmente espera que su compañero de trabajo junior pueda entender ese código y construir sobre él? Y no me refiero a la funcionalidad que ofrece su idioma. Ciertas funciones de Array muy buenas que ofrece JavaScript, por ejemplo.

En el ejemplo anterior, Array.reduce no es algo que un desarrollador Junior pueda entender o por qué funciona de la manera en que funciona, pero no incluye demasiado en una sola línea. Aunque incluso aquí, la función de devolución de llamada podría haber estado en una línea separada para mayor claridad.

¿Pero exprimir la misma funcionalidad en una sola línea que debería estar en varias líneas, solo porque entonces puede afirmar que fue una sola línea? ¡Eso nunca es una buena señal! Degrada la capacidad de mantenimiento de su código y lo hace cada vez más difícil de mantener, especialmente si trabaja en equipo.

Un buen código tiene que ver con el trabajo en equipo y la capacidad de comprender dicho código cuando lo entregas. En el pasado, todos (más o menos) coincidimos en que es malo escribir nombres de variables que no sean descriptivos, deberíamos hacer lo mismo comprimiendo todo el código en menos líneas.

Entonces, la próxima vez que escriba código, pregúntese esto: ¿cree que sus compañeros de trabajo entenderían el código intuitivamente? No necesitan entender el funcionamiento interno, pero ¿captarán lo que hace el código? Por supuesto, todo se reduce a un código autodocumentado, por lo que siempre es algo que debe tener en cuenta.

Algunas reglas que recomendaría que pueden ayudar enormemente a que cualquier código sea más claro:

• Escriba nombres de variables y funciones que tengan sentido en el contexto (código autodocumentado)
• Distribuya el código en varias líneas si la línea hace más de una cosa
• Asegúrese de que cualquier persona que vea el código pueda entender el flujo del código. Y con flujo me refiero a ser capaz de entender cómo se comporta el código, no lo que significan todas y cada una de las funciones.

Si eres nuevo en la programación, sabes cómo funciona el código en general, pero eso no significa que conoces todas y cada una de las funciones que ofrece el lenguaje.

Siempre que pueda explorar el código sin demasiados problemas, y solo verifique la documentación en busca de funciones desconocidas (para el lector de código) del lenguaje, entonces todo estará bien.