I'm currently reading Robert Martin's Clean Code. I think it's great, and when writing OO code I'm taking his lessons to heart. In particular, I think his advice to use small functions with meaningful names makes my code flow much more smoothly. It's best summed up by this quote:
[W]e want to be able to read the program as though it were a set of TO paragraphs, each of which is describing the current level of abstraction and referencing subsequent TO paragraphs at the next level down.
(Clean Code, page 37: a "TO paragraph" is a paragraph that begins with a sentence voiced in the infinitive. "To do X, we perform steps Y and Z." "To do Y, we..." etc.) For example:
TO RenderPageWithSetupsAndTeardowns, we check to see whether the page is a test page and if so, we include the setups and teardowns. In either case we render the page in HTML
I also write functional code for my job. Martin's examples in the book definitely do read as if they were a set of paragraphs, and they're very clear -- but I'm not so sure that "reads like a set of paragraphs" is a desirable quality for functional code to have.
Taking an example out of the Haskell standard library:
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
That is about as far away as you can possibly get from Martin's advice, but that's concise, idiomatic Haskell. Unlike the Java examples in his book, I can't imagine any way to refactor that in to something that has the sort of cadence he asks for. I suspect that Haskell written to the standard of Clean Code would come off as long-winded and unnatural.
Am I wrong to consider (at least some of) Clean Code at odds with functional programming best practices? Is there a sensible way to reinterpret what he says in a different paradigm?