Buenas prácticas para escribir código
Tags: codequality, spanish, programacion
Published: 2020-10-01 22:36:36

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

## :star2: 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 :wrench:

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](https://enmilocalfunciona.io/principios-solid/)

## El código debe ser testeable :mag_right:

¿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.

## :star2: 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.

- Mantenibilidad

Nuestro código podría perdurar en el tiempo y hay que tomar precauciones para que no sea tan difícil de modificar.

- Testeabilidad

Hay que verificar que nuestro código haga lo que se espera y se pueda probar.


## :fire: ¡¡Tengamos mejores códigos!! :rocket: