Buenas Prácticas: La función U.
Esta es una historia como las demás, como todas acerca de esas buenas practicas de código que pueden permitirnos trabajar mejor en equipo, pero esta vez, esta historia tiene su propio nombre como las funciones, la Función U.
En los primeros desarrollos de la compañía donde trabajo me encontré con la tarea de crear una app para hacer comparaciones de datos entre diferentes sources, diferentes databases. En este caso, Oracle y ElasticSearch.
Entre tantas cosas, tenía que transformar las respuestas de cada base de datos a un solo formato. Esto aplicaba para las Fechas, Strings y Enteros de todas las entidades que estaba consultando y operando.
Uno de los casos para transformar strings era con el campo de nombre completo, el cual incluía first, middle y last name. Lo interesante de este punto es que una DB me entregaba todas la variables con la primera letra en mayúsculas en un solo campo y otra, con todas las letras en minúscula y con los campos independientes. La tarea aquí era unir, volver a mayúsculas las primera y comparar. Easy 😛
Acá entra en juego que era mi primera vez escribiendo código usando NodeJS y si bien esto no influyó, lo que sí es que venía de trabajar con PHP usando Laravel, un gran lenguaje y un gran framework con muchos pequeños helpers que hacían la vida un poco más fácil.
Gran parte de esos helpers eran herramientas para ajustar textos, debuggear, imprimir variables y más, gran parte de ellas, llevan por nombre cosas como dd(); e(); now(); tap(); mix() que en su gran mayoría nos ofrecen poca información del contexto o de sus usos. Como lo quieras ver dd() o e() puede ser cualquier cosa.
y aquí lección aprendida: “Crea nombres de variables, funciones y métodos que ofrezcan un contexto de su uso, no seas como yo. “ — Yo
Volviendo a la historia, lo que yo quería hacer era volver cada primera letra a mayúsculas, pues inspirado en mi anterior Framework (laravel) usé el nombre U para llamar a la función que hacía uppercase a la primera letra de cada palabra.
Pude encontrar el PullRequest y el código se veía así:
Puedes notar el comentario antes de declarar la función para explicar cuál al era su comportamiento, lo cual puede darte un warning de que tus variables y funciones no se describen por sí solas. ¿Por qué describirlo en un comentario si la función misma puede describirse?
Cuando llegué al momento del code review, lo primero que vimos fue muchas variables encerradas en una función u(la_variable) , fuera del contexto del comentario que había dejado antes de la declaración era casi imposible saber qué hacia la función:
u(licenseEvent.cd_praes_activity); u(licenseEvent.cd_praes_license);
Así como esas lineas, algunas 30 más intentando darle formato a todas las variables que necesitara.
Al final de cuentas en el code review y con ayuda de mis compañeros llegamos a la idea que lo mejor era llamar a esa función camelCase() y de esta manera ofrecer una rápida descripción de lo que la función hace a los strings.
A este punto entendí fielmente lo que significaba trabajar en equipo, que no era solo mi código, era un código de todos y que debía no solo ser escrito para funcionar bien, sino para que los demás humanos en mi equipo lo entendieran.
En Resumen:
- Las funciones deben describirse por sí misma, tan solo por su nombre.
- Usa si es posible más de una palabra para llegar a una fiel descripción, sin que sea un nombre MUY largo.
- No escribas una misma variable en diferentes idiomas. (Sí, lo he visto)
- Usa estas mismas recomendaciones para los nombres de los parámetros. Si no existe documentación esto puede ser de mucha ayuda para alguien que recién lee el código.
- Por ultimo, consulta con tu equipo, es el código que todos comparten y si no sabes qué usar, entre todos pueden buscar lo mejor.
Eso fue todo! Muchas gracias por leer y recuerda, no más funciones U en nuestro código 🔥
