Free Press

Bienvenido al maravilloso mundo del desarrollo de software. Prepárate para un emocionante viaje lleno de código, reglas y más código. ¿Y he mencionado que hay reglas? Si eres alguien que está familiarizado con la codificación, entonces el concepto de normas de codificación no es nada nuevo para ti. Puede que seas un firme partidario de estas normas o un luchador por la libertad que cree que el código es una forma de expresión. Sea cual sea el caso, no está de más echar un vistazo a algunas de las mejores prácticas a la hora de escribir un buen trozo de código.
Cabe mencionar que, aunque los estándares de codificación existen, lo hacen en muchas variantes y a menudo son meras directrices que no hay que seguir. A menos que quieras escribir un buen código, entonces probablemente deberías ceñirte a alguna forma de estándares.

Escribir comentarios y documentación

Tal vez una de las primeras cosas que aprendes como desarrollador es a comentar tu código. Al principio puede parecer una pérdida de tiempo, siguiendo la mentalidad de ‘Si ellos también son desarrolladores – pueden entenderlo’. Si bien es cierto algunas veces, comentar tu código y proporcionar la documentación adecuada guiará a los otros desarrolladores a través del algoritmo y la lógica que implementaste. Pero no te dejes llevar y comentes cada línea de código. El código obvio debe dejarse tal cual.

Escriba código legible pero eficiente

Los códigos legibles son fáciles de seguir, pero utilizan un espacio y tiempo óptimos. Cuando se escribe código, a menudo se desea escribirlo en el menor número de líneas posible. Tal vez pueda escribir un método o una función entera en una línea, pero eso sólo lo hace más difícil de leer y entender.

Utilice métodos de ayuda

Es una buena práctica mantener el código conciso y sucinto. Un método debe implementar sólo lo que necesita hacer. Si una parte de su implementación hace algo más, póngalo en un método separado y llámelo dentro de su método.

Si es posible evitarlo, ¡no codifique!

Las únicas cosas que deberían codificarse son las constantes. Eso es todo.

Escribe casos de prueba. No olvides los casos extremos: 0s, cadenas/listas vacías, nulls, etc.

De esta forma sabrás lo que hace tu método, lo que toma y lo que debería devolver. Sabrás cuando debe funcionar o cuando debe fallar. Una función debe basarse siempre en casos de prueba; no en pruebas sobre funciones.

Escriba código legible pero eficiente.Cumpla con los estándares de codificación de su proyecto actual

«LAS PRÁCTICAS PERSONALES DISCIPLINADAS PUEDEN REDUCIR LAS TASAS DE INTRODUCCIÓN DE DEFECTOS HASTA EN UN 75 POR CIENTO»

Cada proyecto/empresa tiene sus propios estándares de codificación. Algunos pueden preferir un estilo sobre otro cuando se trata de cosas como las convenciones de nomenclatura, la estructura de los archivos y el espaciado.
Hay IDEs en los que puedes establecer el estilo preferido, que te corregirá automáticamente al guardar. Es más fácil de leer y, por tanto, de entender, cuando todos los archivos de los proyectos utilizan el mismo estilo, convención de nomenclatura, espaciado, etc.

Utiliza el menú desplegable de tu IDE

No es tanto un estándar, sino una buena práctica, son muy útiles y te ayudarán a cometer menos errores de codificación.

Por ejemplo:
Si quieres cambiar el nombre de una variable o un método, sólo tienes que usar la opción «refactor» de tu IDE y cambiará todas las llamadas a ese nombre de método/variable. No tienes que cambiarlas una por una, lo que hará que tu código sea propenso a errores/fracasos.
Si quieres crear métodos getter/setter de todas tus variables privadas, simplemente usa «create getter/setter» y el IDE creará automáticamente los métodos por ti.

Las APIs son útiles

«LOS PROYECTOS DE SOFTWARE ACTUALES DESPILFARRAN ENTRE EL 40 Y EL 50 POR CIENTO DE SU ESFUERZO EN RETIRO EVITABLE»

Antes de implementar un método, asegúrate de que no está disponible para su uso. No tienes que codificar si puedes simplemente importar la funcionalidad. Hace la vida de un desarrollador súper fácil.
El famoso dicho es «No reinventes la rueda» y es cierto en muchos casos. Sin embargo, siempre hay que tener en cuenta las implicaciones de importar una biblioteca, especialmente si es de terceros. Aparte de los posibles problemas de licencia, puedes estar inflando tu código base. Si todo lo que necesitas es un método que convierta temperaturas, no tienes que importar una librería que haga eso y cien cosas más.

Programación por parejas/revisión de código

«Las revisiones por pares captan el 60 por ciento de los defectos»

Estos son muy útiles a la hora de refactorizar tu código. Otros podrían ver una mejor implementación para optimizar su código o simplemente hacer su código más elegante. También asegura que los desarrolladores se adhieren a los estándares y el trabajo se comprueba dos veces. Además de todo eso, es una forma maravillosa de que los desarrolladores aprendan los unos de los otros.

Haz una copia de seguridad y guarda tu trabajo con frecuencia

Basta ya. Una batería agotada, un apagón, un fallo de software, un incendio o una catástrofe nuclear: todo ello puede provocar la pérdida de datos. Asegurarse de guardar a menudo y hacer una copia de seguridad de su código en algún tipo de sistema de control de versiones es una forma sencilla de garantizar que su código se mantiene a salvo.

Los estándares de codificación y las mejores prácticas es un tema enorme – que puede dar para muchas páginas. De hecho, si alguna vez desea leer sobre los estándares de codificación de Java, Oracle tiene precisamente eso. La aplicación de estos estándares y prácticas también varía según la aplicación – ya sea que estés trabajando en un gran proyecto corporativo o ayudando a tu hermano menor con la tarea. En función de muchos factores, en última instancia depende de usted asegurarse de que el código que desarrolle sea un buen código.

Descargo de responsabilidad: Cualquier punto de vista u opinión presentados en esta entrada del blog son únicamente los del autor y no representan necesariamente los de Aversan Inc.