Posted on Oct 1, 2020

Buenas prácticas para escribir código

#codequality #spanish #programacion

Como programadores vamos a leer más código del que vamos a escribir por lo que es importante escribir bien para que entendamos nuestro propio código.

def calcular(a,b):
    return (a*b)/2

Ahora imagina que le muestras ese código que hiciste a algún amigo tuyo que puede ser programador o no. ¿Crees que va a entender qué hace tu código más allá de una multiplicación y división?

Un código bien escrito beneficia a todo el mundo

Es más cómodo de leer
Se entiende qué hace cada función y qué representa cada variable
Te permite disminuir errores
Te permite detectar de forma más rápida en dónde ocurren errores
A la hora de corregir código disminuyes los efectos colaterales
Tu código puede ser entendido por otros y ser usado para proyectos más grandes si tu quieres

Recomendaciones para escribir código

Para escribir código limpio se deben tomar en cuenta estas características:

Legibilidad
Mantenibilidad
Testeabilidad

🌟 El código debe ser legible

El código está escrito para humanos y no para máquinas. A la computadora no le va a importar si defines una variable x=3 o si la llamas vidas=3, pero para una persona este cambio sí genera una diferencia.

¿Te acuerdas de este código?

def calcular(a,b):
    return (a*b)/2

¿Qué te parece si lo mejoramos?

def areaTriangulo(base,altura):
    return (base*altura)/2

Ahora se entiende mejor qué es lo que hacía nuestro código inicial.

Veamos otro ejemplo:

<html><head><title>Mi página de ejemplo</title></head><body>Aquí va el contenido</body></html>

Esto se puede mejorar así:

<html>
    <head>
        <title>Mi página de ejemplo</title>
    </head>
    <body>
    Aquí va el contenido
    </body>
</html>

Otra cosa a tomar en cuenta es que cada lenguaje tiene su estándar de codificación. Puedes buscar en internet para ver cómo se escribe correctamente en cada lenguaje y usar lints para ayudarte. Los lints son herramientas que permiten detectar código sospechoso, que podría generar fallas e incluso si es código confuso.

Visual Studio code puede ayudarte con estos estándares

El código debe ser mantenible 🔧

Esto quiere decir que pueda ser actualizado cada cierto tiempo y que así el programa perdure.

Para esto los consejos son tratar de mantener el código modular, pensar en el código como si fuese un estante ordenado en donde cada módulo interactúa con otros.

Lo otro que hay que tomar en cuenta es que debemos tratar de crear funciones, para que nuestro código sea reutilizable y no estemos repitiendo operaciones una y otra vez sino que sólo llamemos a la función.

Otras cosas que ayudan a la mantenibilidad son: tener el código organizado (con los archivos agrupados en directorios), evitar que funciones hagan cosas que no le correspondan, evitar el hard coding, y si usas programación orientada a objetos (poo) hay que tratar de seguir los principios SOLID.

El hard coding es una mala práctica que consiste en llamar valores de la nada (sin sacarlos de un archivo de configuración o al menos tenerlas como variables).

Ejemplo:
Imagina que vas a desarrollar un programa para una empresa en el que utilizas MUCHO el precio de una compra con iva.

...
print(f"El precio más el 12% de IVA es: {round(precio*1.12)}")
...

El precio más el 12% de IVA es: 112

Si por alguna razón este valor cambia vamos a tener que cambiar todo lo que diga 1.12 de iva.

...
print(f"El precio más el 12% de IVA es: {round(precio*1.15)}")
...

Aún así cambiemos todos los valores, esto imprime mal.

El precio más el 12% de IVA es: 115

Habría que revisar todo el programa un montón de veces para asegurarse de que ese cambio se propague correctamente.

Para resolverlo puedes usar:

...
valor_iva=0.15
print(f"El precio más el {round(valor_iva*100)}% de IVA es: \
{round(precio*(valor_iva+1))}")
...

O crear un archivo aparte en donde tengas todos los valores de configuración y los importes en el programa en donde lo necesites.

Con respecto a SOLID, la idea es cumplir estos 5 principios cuando usamos programación orientada a objetos (POO):

S: Single Reponsibility Principle (cada método se encarga de una única cosa)
O: Open/Closed Principle (cada clase tiene sus métodos)
L: Liskov Substitution Principle (el hijo no puede contradecir al padre en temas de herencia)
I: Interface Segregation Principle (evitar tener interfaces genéricas)
D: Dependency Inversion Principle (evitar dependencia entre clases y usar interfaces)

Si quieres saber más al respecto puedes revisar este post sobre principios SOLID

El código debe ser testeable 🔎

¿Cuánto esfuerzo lleva probar tu código?

Existen las pruebas manuales (realizadas por personas) y las pruebas automatizadas (realizadas por otros programas).

De las pruebas automatizadas hay que tomar en cuenta las pruebas unitarias (las que se prueba un módulo del programa) y las de integración (en donde se prueba cómo interactúan estos módulos entre sí)

Esto es importante porque no sólo nos interesa que nuestro código sea legible y mantenible sino que hay que poder verificar si lo que estamos programando hace realmente lo que debería hacer.

🌟 Recuerda

Legibilidad

Escribimos código para humanos y hay que tratar de ser descriptivos con nuestras variables y funciones y hay que tomar en cuenta los estándares del lenguaje.