En Haskell, suelo escribir expresiones con $ '. Lo encuentro bastante natural y legible, pero a veces leo que es de mala calidad y no entiendo por qué debería ser así.
Respuesta
Los siguientes son todos buenos formulario:
foo = bar . baz . quux
foo x = bar . baz . quux $ x
foo x = (bar . baz . quux) x
foo x = bar (baz (quux x))
yo los he puesto en orden aproximado de mi preferencia, aunque como siempre el sabor varía, y el contexto puede exigir una elección diferente. También he visto de vez en cuando
foo = bar
. baz
. quux
cuando cada uno de los bar
, baz
y quux
subexpresiones son largos. La siguiente es mala forma:
foo x = bar $ baz $ quux $ x
Hay dos razones por las que esto es menos preferible. En primer lugar, se pueden copiar y pegar menos subexpresiones en una definición auxiliar durante la refactorización; con todos los operadores ($)
, solo las subexpresiones que incluyen el argumento x
son refactorizaciones válidas, mientras que con los operadores (.)
y ($)
incluso las subexpresiones como bar . baz
o baz . quux
se pueden extraer en una definición separada.
La segunda razón para preferir (.)
es en previsión de un posible cambio en la fijeza de ($)
; Actualmente, es ($)
infixr
, lo que significa que se asocia a la derecha, así:
foo x = bar $ (baz $ (quux $ x))
Sin embargo, ($)
sería útil en más expresiones si fuera infixl
; por ejemplo, algo así como
foo h = f (g x) (h y)
foo h = f $ g x $ h y
foo h = (f $ g x) $ h y
... que actualmente no se puede expresar sin paréntesis. El ejemplo "de mal gusto", cuando lo analiza con una aplicación infixl
, sería
foo x = ((bar $ baz) $ quux) $ x
que significa algo muy diferente. Por lo tanto, a prueba de futuro su código al evitar esta forma.
También he visto ocasionalmente cosas como 'bar. baz $ quux x' o 'bar (baz. quux $ x)' u otras mezclas, típicamente cuando están involucrados otros operadores de infijo, o cuando se enfatizan conceptualmente aplicaciones de funciones específicas. –
IMO, el argumento de la fijeza es menos convincente que el hecho de que el estilo de composición le permite refactorizar la tubería en una función con un simple cortar y pegar. – ehird
Con su fijeza actual, si tiene 'bar $ baz $ quux $ x', esto es equivalente a' bar. baz. quux $ x'. Este último es, por supuesto, alentado sobre el anterior. –
- 1. ¿Por qué se considera sizeof a un operador?
- 2. ¿Se considera una mala práctica utilizar el posicionamiento absoluto?
- 3. ¿Por qué el ORM se considera bueno pero el "seleccionar *" se considera malo?
- 4. (¿por qué) se considera dañino el selector de estrella CSS?
- 5. ¿Por qué 'para (var item in list)' con arrays se considera una mala práctica en JavaScript?
- 6. Bloquear en un objeto mutable: ¿por qué se considera una mala práctica?
- 7. En C++ 11, ¿se considera un operador?
- 8. ¿Por qué una identificación negativa o cero se considera una mala práctica?
- 9. ¿Se considera mala forma ejecutar una función dentro de una instrucción condicional?
- 10. JSHint considera una variable for-in 'mala'. ¿Qué significa esto?
- 11. ¿Por qué el transformador de mónada ListT se considera defectuoso? ¿Qué leyes de mónada se rompen?
- 12. Notación de dólares en lenguajes de script: ¿por qué?
- 13. ¿Se considera una mala práctica usar atributos HTML no estándar?
- 14. ¿Por qué el cortocircuito y el operador no se cortocircuitan?
- 15. ¿Por qué esta matriz de Java se considera bidimensional?
- 16. ¿Por qué el valor de coma flotante como 3.14 se considera como el doble de forma predeterminada en MSVC?
- 17. ¿Se considera una mala práctica que los objetos ViewModel tengan el Dispatcher?
- 18. ¿Por qué este certificado X.509 no se considera válido?
- 19. Rcov: ¿Por qué este código no se considera cubierto?
- 20. ¿Por qué el operador% se conoce como el operador "módulo" en lugar del operador "restante"?
- 21. ¿Por qué asignar o inicializar NSDateFormatter se considera "costoso"?
- 22. Por qué se considera que HTTP/SOAP es "grueso"
- 23. por qué utilizar Conde con IQueryable se considera inviable
- 24. ¿Por qué anular el operador()?
- 25. ¿Por qué se considera que un "tipo inestable" es malo
- 26. ¿Por qué javascript: void (0) se considera dañino?
- 27. qué operador de llamada nueva forma explícita
- 28. ¿Se considera esto una falla de forma normal?
- 29. ¿Por qué el control de fuente distribuida se considera más difícil?
- 30. ¿El subdominio se considera de dominio cruzado?
¿Tiene una referencia para donde se describe como mala forma? – bobbymcr
Respuesta corta: no. –