El documento habla sobre las buenas prácticas para escribir funciones limpias y claras. Recomienda que las funciones sean cortas, prefieramente no más de 5 líneas, hagan una sola tarea, usen nombres descriptivos y reciban pocos argumentos. También sugiere mantener la sangría a 1 o 2 niveles para mejor legibilidad.

1. Funciones!
Capítulo 3 – Clean Code

2. Funciones
 El objetivo de este capítulo es
básicamente distinguir entre las
buenas y malas prácticas a la hora
de escribir funciones.
 Las funciones son la primera línea
de organización en cualquier
programa.

4. Tamaño
 Reglas para crear funciones óptimas, limpias y claras:
1. Debe ser corta.
2. Debe ser aún más corta.
 Esto permite que la revisión sea mucho más transparente y más eficientes.
Además de que es más entendible para cualquier desarrollador que tuviera
que hacer soporte sobre dicha función.
 Se recomienda escribir funciones entre de máximo 20-30 líneas, lo ideal es
una función de no más de 5 líneas.

5. Bloques y Sangría
 Los bloques que contengan expresiones if, else, while deben ser idealmente
de una sola línea, la cual sería la llamada a otra función.
 Mantener una sangría de 1 nivel, máximo 2. Esto hace a la función mucho más
fácil de leer y de entender

6. Hacer una sola cosa!
 En ocasiones es difícil discernir entre cuando una cosa es solo una o varias.
Por ejemplo: Implementar un login en un aplicativo.
 Lo más recomendable es llevar todo a un nivel de abstracción. Cómo hacerlo?.
Una forma de saber si una función está haciendo una sola cosa es ver si
puedes extraer otra función a partir de ella, es decir, si puedes aislar otra
funcionalidad con un nombre en particular.
 Mantener un solo nivel de abstracción.

7. Usar Nombres Descriptivos
 Facilita la lectura de código y lo hace más entendible al desarrollador.
 Es preferible usar nombres largos y descriptivos que cortos y enigmáticos.
 Ser consistente con los nombres

8. Argumentos
 El número ideal de argumentos para una función es cero. (niladic)
 1 argumento (monadic): writeField(name)
 2 argumentos (dyadic): writeField(output-Stream, name)
Point(x,y)
 3 argumentos (triadic):
makeCircle(double x, double y, double r)  makeCircle(Point center, double r)
 4 o más argumentos (polyadic). Estos requieren un justificación especial para ser
usados, deben ser evitados.
 En la medida de lo posible usar funciones que contengan solo un argumento pues
facilita el entendimiento de la misma. En caso de tener que enviar más de un
argumento, evaluar la posibilidad de enviarlo encapsulado en un objeto o una
estructura.

9. Argumentos
 Evitar no-retornos en funciones las cuales su objetivo sea transformar un
objeto, pues puede ser confuso.
 Void pintarDibujo(Dibujo)  Dibujo Pintar(Dibujo)
 Evitar los argumentos bandera es un error enorme de diseño y es una clara
señal de que la función no hace sólo una cosa, es decir, opera en función del
valor en la bandera.

10. Conclusiones
 En este capitulo se habló de la importancia de la funciones y del hecho de
que estén bien estructuradas y cumplan ciertas características que las hacen
legibles, fáciles de entender, fácil de hacerles mantenimiento y ajustes.
 Entre estas características recordemos las principales:
 Que sean pequeñas
 Que hagan una sola cosa
 Que estén bien nombradas
 Que reciban la menor cantidad de argumentos posibles