Pequeñas. La primera regla para las funciones es que deben de ser pequeñas. La segunda es que las funciones deben de
ser mas pequeñas que ellas mismas. Las lineas de una funcion no deberian de tener mas de 150 carateres, el numero de
lineas no debe pasar las 100 (las funciones casi nunca deben de pasar las 20 lineas)
Unico proposito. Las funciones deberan tener un unico proposito, deberan hacerlo bien y que esto sea lo unico que hagan.
Una forma de conocer si una funciones está haciendo mas de una cosa es si se puede extraer otra función de ella con
un nombre que no sea simplemente una reexpresión de su implementación.
Un nivel de abstracion por funcion. Para poder asegurar que que una funcion solo hace "una cosa" nedecitamos
asegurarnos que las instruccones en ella están todas en el mismo nivel de abstracion.
Leyendo el codigo de arriba abajo - La regla Stepdown. Es bueno poder leer el codigo de arriba abajo, para ello
escribiremos las funciones en orden de abstraccion, descendiendo un nivel de abstraccion cada vez que leamos hacia
abajo en nuestra lista de funciones.
Sentencias Switch. Por normal general podemos tolerar estas estructurassi si aparecen solo una vez, son usadas
para creadar objetos polimorficos y estan ocultas trasn una relaccion de herencia que el resto del sistema no puede ver.
Esta no es una regla estricta y dependiendo del caso podemos saltarnosla.
Usa nombre descriptivos. Un nombre descriptivo largo es mejor que uno corto y enimgatico. Un nombre descriptivo
largo es mejor que un comentario descriptivo y largo. Se consistente en tus nombres, Usa las mismas frases, nombres
y verbos el nombre nombres de funcion que elijas para tus modulos.
Argumentos en funciones. El numero ideal de argumentos de una funcion es 0 (niladic). Seguido de 1 (monadic),
seguido por 2 (dyadic). · argumentos (triadic) deberan de ser evitados cuando sea posible. Mas de tres (polyadic)
requerirá una justificacion muy especial y no debn ser usados de ninguna forma. Los argumentos son dificiles. Tienen
mucho poder conceptual. Desde el punto de vista de testing son aun mas dificiles.
Usos comunes de metodos monadic. Existen dos razones comunes para pasar un solo argumentos a una funcion.
Preguntar algo sobre el argumento (boolean isNumber("234")) u operar sobre el argumento, transformarlo en cualquier
otra cosa y devolverlo. Intenta evitar funciones monadic que usen como objeto de salida para devolver lo ocurrido en
el objeto de entrada
Argumentos usados como Flag. Argumentos usados como flag son horribles. Pasar un boolean a una funcion es una
practica verdaderamente terrible.
Funciones dyadic. Debemos prestar especial atencion a las funciones con dos argumentos del tipo
assertEquals(expected, actual) son problematicas. Estos parametros no tienen un orden natural.
Objetos en argumentos. Cuando una funcion neceites dos o mas argumentos, es preferifble que estos argumentos se
encapsulen en una clase.
Listas de argumentos. Cuando los argumentos de metodo son variable, lo idial será encapsularlo en un objeto de
tipo List.
Verbos y palabras clave. En los nombres de las funciones con mas de un argumento podemos usar los nombres de los
argumentos dentro del nombre de la funcion, por ejemplo, assertExpectedEqualsActual(expected, actual). Con esto mitigamos
el problema de tener que recordar el orden de los parametros
Tener efectos secundarios. Evita hacer llamadas o cualquier otra cosa que no tenga nada que ver dentro de la
funcion que estas creando, este efecto crea un acoplamento temporal.
Argumentos de salida. Los argumentos naturalmente son las entradas de una funcion, si existen argumentos de salida,
tendrás que volver a comprobar la firma de la función. En general los argumentos de entrada deben de ser evitados. Si
tu funcion debe cambiar el estado de algo, haz el cambio de estado en su propio objeto.
Command Query Separation. Las funciones deben de hacer algo o de contestar algo, pero no ambos. Hacer las dos lleva
a confusion.
Excepciones frente a codigos de retorno.Devolver codigos de error es una sutil violacion de la regla anterior. Al
devolver codigos de error, estos pueden ser usados en las sentencias if, lo que puede llevar a profundas estructuras
anidades de sentencias if. Por tanto lo ideal será detener la continuidad del codigo con una execpcion consiguiendo que
nuestro happy path esté completamente separado del procesamiento de errores.
Bloques try/catch. Procuraremos extraer los cuerpos de los bloques try y catch fuera, a sus propias funciones.
Programacion estructurada. Cada funcion y cada bloque dentro de una funcion debe de tener una entrada y una salida.
Siguiente esta regla deberemos tener solo un return en nuestro funcion, no tener break o continue en un bucle y nunca
tener un goto.