He cambiado el código de dos veces recientemente para cambiar el orden de los parámetros porque había demasiados códigos en los que se producían hacks como flip o \x -> foo bar x 42 .
Al diseñar una función, ¿qué principios me ayudarán a aprovechar al máximo el currículum?
Para lenguajes que soportan currying y parcial-application fácilmente, hay una serie convincente de argumentos, originalmente de Chris Okasaki:
¿Por qué? A continuación, puede componer las operaciones en los datos muy bien. Por ejemplo, insert 1 $ insert 2 $ insert 3 $ s . Esto también ayuda a las funciones de estado .
Las bibliotecas estándar como “contenedores” siguen esta convención .
A veces se dan argumentos alternativos para poner la estructura de datos primero, de modo que se puede cerrar, produciendo funciones en una estructura estática (por ejemplo, búsqueda) que son un poco más concisas. Sin embargo, el amplio consenso parece ser que esto no es tan exitoso, especialmente porque lo empuja hacia un código entre paréntesis.
Para las funciones recursivas, es común poner el argumento que más varía (por ejemplo, un acumulador) como último argumento, mientras que el argumento que menos varía (por ejemplo, un argumento de función) al comienzo. Esto se combina bien con la estructura de datos del último estilo.
Se proporciona un resumen de la vista de Okasaki en su biblioteca de Edison (una vez más, otra biblioteca de estructura de datos):
Coloque los argumentos que es más probable que reutilice primero. Los argumentos de función son un gran ejemplo de esto. Es mucho más probable que desee map f sobre dos listas diferentes, que desea mapear muchas funciones diferentes sobre la misma lista.
Tiendo a hacer lo que hizo, elegir un orden que parece bueno y luego refactorizar si resulta que otro orden es mejor. El orden depende mucho de cómo vas a usar la función (naturalmente).