Actualmente estoy leyendo el Código Limpio de Robert Martin . Creo que es genial, y cuando escribo código OO, tomo sus lecciones muy en serio. En particular, creo que su consejo de usar funciones pequeñas con nombres significativos hace que mi código fluya mucho más suavemente. Se resume mejor con esta cita:
[W] Deseamos poder leer el programa como si fuera un conjunto de párrafos TO, cada uno de los cuales describe el nivel actual de abstracción y hace referencia a los siguientes párrafos TO en el siguiente nivel inferior.
( Código limpio , página 37: un "párrafo TO" es un párrafo que comienza con una oración expresada en infinitivo. "Para hacer X, realizamos los pasos Y y Z". "Para hacer Y, nosotros ...", etc. ) Por ejemplo:
PARA RenderPageWithSetupsAndTeardowns, verificamos si la página es una página de prueba y, de ser así, incluimos las configuraciones y desmontajes. En cualquier caso, representamos la página en HTML
También escribo código funcional para mi trabajo. Los ejemplos de Martin en el libro definitivamente se leen como si fueran un conjunto de párrafos, y son muy claros, pero no estoy tan seguro de que "lea como un conjunto de párrafos" sea una cualidad deseable para que el código funcional tenga .
Tomando un ejemplo de la biblioteca estándar de Haskell :
maximumBy :: (a -> a -> Ordering) -> [a] -> a
maximumBy _ [] = error "List.maximumBy: empty list"
maximumBy cmp xs = foldl1 maxBy xs
where
maxBy x y = case cmp x y of
GT -> x
_ -> y
Eso es lo más lejos posible del consejo de Martin, pero ese es Haskell conciso e idiomático. A diferencia de los ejemplos de Java en su libro, no puedo imaginar ninguna forma de refactorizar eso en algo que tenga el tipo de cadencia que solicita. Sospecho que Haskell, escrito según el estándar del Código Limpio, se consideraría insoportable y antinatural.
¿Me equivoco al considerar (al menos algunos de) Clean Code en desacuerdo con las mejores prácticas de programación funcional? ¿Hay alguna manera sensata de reinterpretar lo que dice en un paradigma diferente?
xs
es un mal nombre, pero es tan común en los lenguajes funcionales como i
en las variables de bucle.