¿Es necesario tener un código de programación estándar?

Hay una frase muy común entre los programadores:

“Si funciona, no lo toques.”

A veces, un simple cambio en el código puede desatar un serie de errores desafortunados. Imagino que debido a esto, y al doble trabajo que pueda representar, los desarrolladores evitamos refactorizar el código a menos que sea muy necesario.

¿Por qué los programadores tienen miedo de cambiar el código?

Quizás se deba a:

• Falta de confianza. No confían en sus cambios. ¿Funcionará o romperá otro código dependiente?
• Si no funciona, ¿qué cantidad de tiempo se perderá?
• No están seguros acerca de las pruebas de regresión.

Herramientas de análisis de código

Hay millones de desarrolladores en todo el mundo que tienen miedo de cambiar o refactorizar el código que ya es funcional.

Sin embargo, en esta era de hacer aplicaciones y sistemas más robustos, eficientes, y escalables, tomando en cuenta también su mantenimiento a futuro, se busca estandarizar o mejorar la legibilidad del código.

Para ello los programadores utilizamos alguna herramienta de análisis estático de código, que se utiliza para comprobar que el código cumple con una serie de reglas de estilo.

Solo por mencionar algunas herramientas, en JavaScript está ESlint y para desarrollar en Kotlin ahora se tiene el llamado Ktlint.

Al principio, se vuelve un poco molesto utilizar estas herramientas porque cada sintaxis incorrecta provocará un error, incluso algo simple como un espacio, una tabulación de más en una línea…Tendrás que corregir el código antes de ponerlo en funcionamiento, aunque tu lógica sea buena, además de que cada desarrollador tiene su propio estilo al programar.

Pero ese es el punto, no tener un mismo código con diferentes estilos, sino estandarizar.

En ocasiones, los desarrolladores están cansados de mirar su editor todo el día. Son pequeños errores, pero aún así deben corregirse. Además, a veces olvidamos eliminar las declaraciones de importación no utilizadas. 

¿Alguna vez olvidaste limpiar un console.log()?

Por esos pequeños detalles que se nos pasan, la herramienta puede atrapar esos códigos y devuelve un error.

Principalmente, hay que tener en cuenta que las reglas de los linters se dividen en dos categorías:

Reglas de formato

Por ejemplo: longitud de línea máxima, tipo de indentación, tamaño de la indentación…

Reglas de calidad del código

Por ejemplo: no permitir variables que no se usen, no permitir declaraciones de variables globales…

Son las más importantes que ofrecen los linters ya que pueden detectar errores en el código.

Pero, como ha dicho Sam Roberts, un experto Ingeniero de Programación en IBM Canadá:

Los proyectos bien ejecutados tienen convenciones de codificación claras y consistentes, con aplicación automatizada. Cuando reviso un proyecto, y su código parece una casa construida por un niño usando nada más que un hacha y una foto de una casa, no inspira confianza en que el código sea funcional.

¿Estamos listos para este cambio de código?

Ahora preguntaré:

¿Tienes un proyecto en producción desde hace años, con múltiples módulos al cual le hacen mantenimiento varios desarrolladores, sin tener el código estandarizado?

¿Estás abierto a estandarizar todo el proyecto?

¿Piensas en el tiempo que tomará?

¿Y si afecta la funcionalidad actual del producto?

Recientemente, en mi trabajo surgió la propuesta de parte de una de los desarrolladores, de aplicar Ktlint a todo el repositorio del proyecto, de manera de tener un formato estándar siguiendo los guidelines definidos por Kotlin.

Ese es el principal beneficio que trae consigo, además de otros beneficios menores pero significativos, como hacer code review de código modificado por feature/bug y no en otras líneas donde solo es formato, que puede ser un poco repetitivo desde mi punto de vista y no necesariamente todos los Android Studio del equipo están configurados de la misma manera, con esto podríamos asegurar eso.

¿Qué opinan los programadores?

Se tomó la decisión por votación y estas fueron algunas opiniones:

“Me parece buena la idea de tener iniciativas para mejorar el proyecto. Yo soy de la vieja escuela, no me gustan los cambios masivos (aunque en este caso es solo cambio de formato). Si el cambio es muy grande y aporta poco, quizás no sea el momento de aplicarlo. Conclusión: Por mí es un no, pero sigamos aportando ideas”.

“No veo grandes cambios en el formato, el más grande es en los data class. Por otro lado, no veo qué otra ventaja, además de tener un estándar, nos pueda traer esto. Quizás estoy equivocado. En mi opinión, no lo veo tan necesario. Por otro lado, si la decisión es usarlo se pueden configurar la reglas y dejamos los formatos que consideremos más importantes”.

“Pues he leído sobre eso un poco y teniendo en cuenta que los comentarios de tabulación se pueden configurar para que al hacer Commit no te deje hacerlo si no cumple el formato, y que se parece al Eslint que se usa en un entorno web para estandarizar el código, para mí es un sí. Se ahorrarían comentarios en los PR”.

“Creo que esto de “ahorrar comentarios” debería ser más parte de nosotros, no deberíamos esperar a mandar un PR para que nos digan que una línea está mal formateada, agradezco la iniciativa y espero que todos seamos parte de esto, que propongamos cosas y no los limitemos a lo que ya hay. Teniendo en cuenta esto, creo que el valor que puede llegar a aportar es poco”.

Como podemos ver, no es un cambio fácil. En mi opinión, garantiza que todos hablen el mismo idioma al escribir un código. Esta también será una gran herramienta para incorporar nuevos miembros a su equipo y que se adapten al estilo de trabajo más fácil y rápido.

El uso de un linter le permite a su equipo dejar de lado las preferencias personales y seguir las pautas aceptadas por la mayoría.

Para leer más acerca de Ktlint y su configuración puedes hacer click aquí y para ESlint aquí.

Algunas ventajas

• Legibilidad.
• Revisión previa al código.
• Encontrar errores (sintaxis) antes de la ejecución.
• El formato de nuestro código mantiene cierta homogeneidad.
• Configurar nuestras propias reglas, o bien usar algunas de las extensiones de estilo que ya usan ciertas empresas, como por ejemplo Google o AirBnB.
• Configuración para que se ejecute antes de un Commit.

¿Desventajas?

• La configuración puede parecer algo compleja.

Cuéntanos en los comentarios, tu opinión sobre la estandarización del código y sobre qué hubieras votado tú. Tal vez es momento de cambiar la frase a “Si funciona, ¡Mejóralo!”.