javascript - entre - ¿Las funciones anónimas se consideran dañinas?
funciones lambda javascript (8)
Cuanto más profundizo en javascript, más pienso en las consecuencias de ciertas decisiones de diseño y prácticas recomendadas. En este caso, estoy observando funciones anónimas, una función que no solo está provista por JavaScript, sino que veo muy utilizada.
Creo que todos podemos estar de acuerdo en los siguientes hechos:
- la mente humana no se ocupa de más de 7 más menos dos entidades ( ley de Miller )
- La sangría profunda se considera una mala práctica de programación y, en general, señala problemas de diseño si se sangran más de tres o cuatro niveles. Esto se extiende a las entidades anidadas, y está bien presentado en la entrada de Python Zen "Plano es mejor que anidado".
- La idea de tener un nombre de función es tanto para referencia como para facilitar la documentación de la tarea que realiza. Sabemos, o podemos esperar, lo que hace una función llamada removeListEntry (). La autodocumentación y el código claro son importantes para la depuración y la legibilidad.
Si bien las funciones anónimas parecen ser una característica muy agradable, su uso conduce a un diseño de código profundamente anidado. El código es rápido de escribir, pero difícil de leer. En lugar de ser forzado a inventar un contexto con nombre para una funcionalidad y aplanar la jerarquía de objetos a los que se puede llamar, fomenta un "nivel profundo", empujando su pila de cerebros y desbordando rápidamente la regla 7 +/- 2. Un concepto similar se expresa en " Acerca de la cara " de Alan Cooper, citando de manera general "la gente no entiende las jerarquías". Como programadores entendemos las jerarquías, pero nuestra biología todavía limita nuestra comprensión de la anidación profunda.
Me gustaría escucharte sobre este punto. ¿Deberían las funciones anónimas ser consideradas dañinas, un azúcar aparentemente brillante y sintáctico que luego encontramos sal, o incluso veneno para ratas?
CW ya que no hay respuesta correcta.
A quien se le ocurrió la idea de exigir que las funciones estuvieran vinculadas a los identificadores, todo programador fue perjudicial. Si nunca ha realizado la programación funcional y no está familiarizado con las funciones y no se siente cómodo con ellos, no es un verdadero programador.
De hecho, para contrarrestar su propio argumento, me atrevería a considerar que las funciones vinculadas a nombres (globales) son perjudiciales. Consulte el artículo de Crockford sobre miembros privados y públicos y aprenda más.
Como lo veo, el problema al que te enfrentas no son las funciones anónimas, sino una falta de voluntad para dividir la funcionalidad en unidades útiles y reutilizables. Lo que es interesante, porque es más fácil reutilizar la funcionalidad en idiomas con funciones de primera clase (y, necesariamente, funciones anónimas) que en idiomas sin ellos.
Si ve muchas funciones anónimas profundamente anidadas en su código, sugeriría que puede haber una gran cantidad de funciones comunes que se pueden descomponer en funciones de orden superior denominadas (es decir, funciones que aceptan o devuelven ("crean") otras) funciones). Incluso las transformaciones "simples" de las funciones existentes deben recibir nombres si se usan con frecuencia. Este es solo el principio DRY.
Creo que los cierres tienen enormes beneficios que no deben pasarse por alto. Por ejemplo, Apple aprovecha los "bloques" (cierres para C) con GCD para proporcionar multiprocesamiento múltiple, no es necesario configurar estructuras de contexto, y solo puede hacer referencia a las variables por su nombre, ya que están dentro del alcance.
Creo que un problema mayor con Javascript es que no tiene un alcance de bloque (en este caso, los bloques se refieren al código entre llaves, como una instrucción if). Esto puede llevar a enormes complicaciones, obligando a los programadores a utilizar cierres innecesarios para sortear esta limitación de diseño de Javascript.
Curiosamente, JavaScript te permitirá nombrar funciones "anónimas":
function f(x) {
return function add(y) {
return x+y;
};
}
En realidad, las jerarquías ayudan a superar 7 +/- 2 reglas de la misma manera que OOP. Cuando estás escribiendo o leyendo una clase, lees su contenido y nada de código externo, por lo que estás tratando con una porción relativamente pequeña de entidades. Cuando estás viendo jerarquías de clases, no miras dentro de ellas, lo que significa que nuevamente estás tratando con un pequeño número de entidades.
Lo mismo si es verdad para funciones anidadas. Al dividir su código en múltiples niveles de jerarquía, mantendrá cada nivel lo suficientemente pequeño como para que lo pueda comprender el cerebro humano.
Los cierres (o funciones anónimas) solo ayudan a dividir el código de una forma ligeramente diferente a la de OOP, pero en realidad no crean jerarquías. Están aquí para ayudarlo a ejecutar su código en el contexto de otro bloque de código. En C ++ o Java tienes que crear una clase para eso, en la función JavaScript es suficiente. Por supuesto, la clase independiente es más fácil de entender, ya que es más fácil para los humanos verla como en un bloque independiente. La función parece ser mucho más pequeña en tamaño y el cerebro a veces piensa que puede comprenderla Y codificar a su alrededor al mismo tiempo, lo que suele ser una mala idea. Pero puedes entrenar tu cerebro para no hacer eso :)
Así que no, no creo que las funciones anónimas sean dañinas en absoluto, solo tienes que aprender a lidiar con ellas, como aprendiste a lidiar con las clases.
Las funciones anónimas son más útiles funcionalmente que dañinas de forma legible. Creo que si formateas tu código lo suficientemente bien, no deberías tener un problema. No tengo ningún problema con eso, y estoy seguro de que no puedo manejar 7 elementos, y mucho menos 7 + 2 :)
Si una función no es comprensible sin un nombre, es probable que el nombre sea demasiado largo. Use comentarios para explicar el código críptico, no confíe en los nombres.
También creo que las funciones anónimas (en los últimos lenguajes a menudo denominadas cierres) tienen grandes beneficios y hacen que el código sea más fácil de leer y más corto. A veces me estoy volviendo loco cuando tengo que trabajar con Java (donde los cierres no son funciones de lenguaje de primera clase).
Si el problema es la sangría y demasiadas variables de función encapsuladas, debe refactorizar el código para que sea más modular y legible.
Con respecto a java-script, creo que las variables de función se ven bastante feas y hacen que el código esté desordenado (la cadena encapsulada de la función (...) {} hace que el código de java-script sea menos legible). Como ejemplo, prefiero la sintaxis de cierre de groovy (caracteres ''{}'' y ''->'').