Aplicar los principios de Clean Code a los lenguajes funcionales

14

Actualmente estoy leyendo Clean Code de Robert Martin . Creo que es genial, y cuando escribo el código OO me tomo muy en serio sus lecciones. En particular, creo que su consejo para usar funciones pequeñas con nombres significativos hace que mi código fluya con mayor facilidad. Es mejor resumirlo con esta cita:

  

[W] Queremos poder leer el programa como si fuera un conjunto   de los párrafos TO, cada uno de los cuales describe el nivel actual de abstracción y hace referencia a los párrafos TO subsiguientes en el siguiente nivel hacia abajo.

( 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". haz S, nosotros ... "etc.) Por ejemplo:

  

A RenderPageWithSetupsAndTeardowns, verificamos si la página es una página de prueba y, de ser así, incluimos las configuraciones y los desmontes. 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 seguro de que "leer como un conjunto de párrafos" sea una calidad deseable para el código funcional. .

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 que puedes obtener de los consejos de Martin, pero eso es conciso, idiomático Haskell. 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 pide. Sospecho que Haskell escrito a la norma de Código limpio saldría como algo largo y poco natural.

¿Me equivoco al considerar (al menos algo de) Código limpio en desacuerdo con las mejores prácticas de programación funcional? ¿Hay una manera sensata de reinterpretar lo que dice en un paradigma diferente?

    
pregunta Patrick Collins 28.08.2014 - 00:14

2 respuestas

10

Clean Code es, ante todo, un manual de estilo. Strunk and White no se aplica cuando escribes en klingon. La idea es que quiera ser claro para los programadores que probablemente leerán su código. Desea tener un código que sea modular y fácil de reestructurar. Hay formas de hacer esto en Haskell, al igual que hay formas de hacerlo en cualquier otro idioma, pero los detalles precisos variarán.

Dicho esto, hay una serie de directrices de estilo por ahí para Haskell. Stack Overflow también tiene una guía bastante completa. Mantener la lógica de codificación directa y breve parece ser bastante constante. También se enfatiza la generalización de las funciones, ya que conduce a la modularidad. El código DRY también se destaca, al igual que con el código limpio.

Al final, las pautas de codificación de Clean Code y Haskell se esfuerzan por lograr lo mismo, pero terminan tomando sus propios caminos para llegar allí.

    
respondido por el World Engineer 28.08.2014 - 00:41
12

No estoy seguro de seguir lo que quieres decir con tu ejemplo. Los párrafos, tal como los describe, no requieren un aliento largo. Él no quiere decir que el código debe leerse como en inglés. La parte importante es la agrupación de funcionalidades en el mismo nivel de abstracción, en una progresión lógica. Es un concepto estructural teórico que trasciende los paradigmas de programación.

Expresado en el formato "A párrafo" de Bob Martin, leí su ejemplo como:

  • Para calcular el maximumBy , necesita una función de pedido y una lista, y el resultado es un elemento de esa lista.
  • Para calcular el maximumBy de una lista vacía y cualquier función de ordenamiento es un error.
  • Para calcular el maximumBy de una lista xs , dobla esa lista usando la función maxBy .
  • Para calcular el maxBy de dos elementos de la lista, puede compararlos utilizando la función de orden dada. Si el primer elemento es mayor, elíjalo. De lo contrario, elige el segundo.

Está comenzando con los conceptos más generales y avanzando a más detalles, como en los ejemplos imperativos. La idea de los "párrafos TO" es que puedes dejar de leer en un momento determinado cuando hayas obtenido suficientes detalles, sin tener que saltar hacia arriba y hacia abajo en la página. Ese es ciertamente el caso aquí.

Un par de nombres podrían ser mejores, pero son convenciones comunes del lenguaje, especialmente al escribir funciones genéricas de orden superior. Los nombres de funciones de orden superior tampoco se traducen bien en frases verbales imperativas como los ejemplos en el libro, porque describen más las relaciones entre verbos.

Hay formas de implementar esto que no siguen las pautas de "TO párrafo". Si se deja la firma de tipo explícita, se omitirá la oración de "descripción general" de nivel superior. Podría usar una expresión if para el manejo de errores en lugar de la coincidencia de patrones, lo que podría confundirla de manera inapropiada con otro nivel de abstracción. Podría incluir maxBy como una función anónima en lugar de darle un nombre que pueda describirse más adelante con más detalle.

De hecho, creo que las construcciones como where en realidad son mejores adecuadas para el formato de párrafo, porque puedes usarlas para dar un nombre a un detalle más profundo de una manera que sea similar a cómo Lo expresamos en inglés y, de manera similar, limitamos su alcance de manera clara al contexto del "párrafo".

    
respondido por el Karl Bielefeldt 28.08.2014 - 03:05

Lea otras preguntas en las etiquetas