TL; DR
Las funciones de flecha están bien para ciertos usos, pero tienen tantas variaciones que necesitan ser controladas cuidadosamente para no desglosar la legibilidad del código.
Mientras que las funciones de flecha claramente tienen una ubicua Por consenso de la comunidad (¡aunque no es un apoyo unánime!), resulta que hay una gran variedad de opiniones sobre lo que hace un uso "bueno" de => y no.
Las reglas configurables de la plataforma son la mejor solución para la disputa la variedad y el desacuerdo de las funciones de flecha.
Liberé proper-arrows El complemento de ESLint con varias reglas configurables para controlar => funciones de flecha en su código base. [19659007] Las opiniones son como narices …
Cualquiera que me haya seguido (tweets, libros, cursos, etc.) sabe por mucho tiempo que tengo muchas opiniones. De hecho, eso es lo único en lo que soy un experto, mis propias opiniones, ¡y nunca me siento en falta para ellos!
No me suscribo al mantra de "opiniones firmes y poco firmes". No "sostengo" libremente mis opiniones porque no veo ningún punto en tener una opinión si no hay razón suficiente para esa opinión. Dedico mucho tiempo a investigar, a hacer pequeños retoques, a escribir ya probar ideas antes de formarme una opinión que compartiría públicamente. En ese punto, mi opinión es bastante firme, por necesidad.
Además, enseño en base a estas opiniones, miles de desarrolladores en diferentes compañías de todo el mundo, lo que me brinda la oportunidad de analizar mis opiniones en profundidad. a través de innumerables debates y discusiones. Tengo el tremendo privilegio de estar en esa posición.
Eso no significa que no pueda o no cambiaré mis opiniones. De hecho, una de mis opiniones más firmes (que los tipos y coerción de JS son útiles en JS) ha estado cambiando últimamente, en un grado bastante significativo. Tengo una perspectiva mucho más redondeada y profunda sobre los tipos de JS y por qué el uso de herramientas de tipo puede ser útil. E incluso mi opinión sobre => funciones de flecha, la línea de remate de este artículo, ha evolucionado y se ha profundizado.
Pero una de las cosas que muchas personas dicen que aprecian de mí es que no solo Estado de opiniones, respaldo esas opiniones con un razonamiento cuidadoso y pensado. Incluso cuando la gente discrepa vehementemente con mis opiniones, a menudo me felicitan por al menos ser dueño de esas opiniones con respaldo.
Y trato de inspirar lo mismo en otros a través de mi forma de hablar, enseñar y escribir. No me importa si está de acuerdo conmigo, solo me importa saber por qué tiene una opinión técnica y puede defenderla seriamente con su propia línea de razonamiento. Para mí, esa es una relación sana con la tecnología.
¡Funciones de flecha! = función s
Creo sinceramente que la función de flecha => no es adecuada como una reemplazo general para todas las funciones (o incluso la mayoría) en su código JS. Realmente no los encuentro más legibles en la mayoría de los casos. Y no estoy sola. Cada vez que comparto una opinión como esa en las redes sociales, a menudo recibo docenas de "¡yo también!" las respuestas salpicaron con las puntuaciones de "¡estás totalmente equivocada! respuestas".
Pero no estoy aquí para repetir todo el debate sobre => funciones de flecha. He escrito mucho sobre mis opiniones sobre ellos, incluidas estas secciones en mis libros:
Sean cuales sean sus preferencias en torno a => para sugerir que es solo a mejor la función debe ser claramente reductiva. Es un tema mucho más matizado que solo una correspondencia uno a uno.
Hay cosas que me gustan de => . Puede que le resulte sorprendente a mí ya que la mayoría de la gente parece asumir que odio las funciones de flecha.
No (los odio). Creo que definitivamente hay algunos beneficios importantes.
Es solo que no los endoso sin reservas como la nueva función . Y en estos días, la mayoría de la gente no está interesada en opiniones matizadas en el medio. Entonces, como no estoy completamente en el campo pro => debo estar completamente en el campo de la oposición. No es cierto .
Lo que odio es sugerir que son universalmente más legibles, o que son objetivamente mejor en casi todos los casos.
La razón por la que rechazo La postura es porque REALMENTE LUCGO POR LEERLOS en muchos casos. Así que esa perspectiva me hace sentir tonto / inferior como desarrollador. "Debe haber algo mal conmigo, ya que no creo que sea más legible. ¿Por qué apesto tanto con esto?" Y no soy el único cuyo síndrome de impostor está muy afectado por tales absolutos.
Y la guinda es cuando la gente te dice que la única razón por la que no entiendes o te gusta => es porque no los has aprendido ni los has usado lo suficiente. Ah, sí, gracias por el recordatorio (condescendiente) que se debe a mi ignorancia e inexperiencia. SMH. He escrito y leído literalmente miles de funciones => . Estoy bastante seguro de que sé lo suficiente sobre ellos como para tener las opiniones que tengo.
No estoy en el campo de programas => pero reconozco que algunos realmente los prefieren, legítimamente. Reconozco que algunas personas vienen a JS de lenguajes que han usado => y por eso sienten y leen bastante natural. Reconozco que algunos prefieren su parecido con la notación matemática.
Lo que es problemático La OMI es cuando algunos en esos campos simplemente no pueden entender o simpatizar con las opiniones disidentes, como si simplemente hubiera algo equivocado con ellos. 19659007] Readability! = Writability
Tampoco creo que usted sepa de qué está hablando cuando habla sobre la legibilidad del código. En general, la gran mayoría de las opiniones sobre la legibilidad del código, cuando se desglosan, se basan en una postura personal sobre las preferencias al escribir el código conciso .
Cuando rechazo los debates sobre la legibilidad del código , algunos simplemente cavan en sus talones y se niegan a apoyar su opinión. Otros renunciarán a las preocupaciones con "la legibilidad es simplemente subjetiva de todos modos".
La fragilidad de esa respuesta es sorprendente: hace dos segundos reclamaban con vehemencia => la flecha es absoluta y objetivamente más legible y luego, cuando se les presiona, admiten: "bueno, Yo creo que es más legible, incluso si los ignorantes como usted no lo hacen".
¿Adivina qué? La legibilidad es subjetiva, pero no del todo . Es un tema realmente complejo. Y hay algunos que se comprometen a estudiar formalmente el tema de la legibilidad del código, a tratar de encontrar qué partes de él son objetivas y cuáles son subjetivas.
He leído una buena cantidad de dicha investigación y estoy convencido que es un tema suficientemente complicado que no puede reducirse a un eslogan en una camiseta. Si quieres leerlos, te animo a que hagas una búsqueda en Google y leas por ti mismo.
Si bien no tengo todas las respuestas, una cosa es cierta, el código se lee con más frecuencia que escrito, por lo que las perspectivas sobre el tema que en última instancia provienen de "es más fácil / más rápido de escribir" no se mantienen en pie. Lo que se debe tener en cuenta es, no cuánto tiempo ahorra en escritura, pero ¿con qué claridad podrá entender el lector (en el futuro usted o alguien más en el equipo)? E idealmente, ¿pueden entenderlo en su mayor parte sin verter el código con un peine de dientes finos?
Cualquier intento de justificar la capacidad de escritura con afirmaciones no fundamentadas sobre beneficios de legibilidad es un argumento débil en el mejor de los casos, y en general, no es más que una distracción. .
Así que rechazo rotundamente que => sea siempre y objetivamente "más legible".
Pero todavía no odio las funciones de flecha. Pienso que para usarlos de manera efectiva, debemos ser más disciplinados.
Linters == Discipline
Es posible que piense (incorrectamente) que los linters le informan datos objetivos sobre su código. Ellos pueden hacer eso, pero ese no es su propósito principal.
La herramienta más adecuada para decirle si su código es válido es un compilador (es decir, el motor JS). La herramienta más adecuada para decirle si su código es "correcto" (hace lo que usted quiere que haga) es su conjunto de pruebas.
Pero es la herramienta más adecuada para decirle si su código es apropiado es un linter. Los linters son colecciones de reglas con opiniones sobre cómo debe diseñar y estructurar su código para evitar posibles problemas, de acuerdo con los autores de esas reglas basadas en opiniones.
Para eso se aplican: Opiniones a su código.
Eso significa que es casi seguro que estas opiniones, en un momento u otro, lo "ofenderán". Si eres como la mayoría de nosotros, te apetece lo que haces, y sabes que esta cosa que estás haciendo en esta línea de código es correcta . Y luego aparece la plantilla y dice: "No, no lo hagas de esa manera".
Si tu primer instinto es a veces en desacuerdo, ¡entonces serás como el resto de nosotros! Nos apegamos emocionalmente a nuestras propias perspectivas y habilidades, y cuando una herramienta nos dice que estamos equivocados, repiqueteamos un poco.
No me enojo con la suite de pruebas ni con el motor JS. Esas cosas son todas informes hechos sobre mi código. Pero definitivamente puedo irritarme cuando la opinión de de la impresora no está de acuerdo con la mía.
Tengo esta única regla de la memoria que habilité hace unas semanas, porque tenía una inconsistencia en mi codificación que me molestaba el código vuelve a leer. Pero ahora esta regla de pelusas aparece dos o tres veces por hora, y me molesta como una abuela estereotipada en una comedia de los 90. Cada vez, reflexiono (solo por un momento) si debo deshabilitar esa regla. Lo dejo encendido, pero para mi disgusto.
¿Entonces por qué someternos a este tormento? Porque las herramientas de linter y sus opiniones son las que nos dan disciplina. Nos ayudan a colaborar con otros.
En última instancia, nos ayudan a comunicarnos más claramente en código.
¿Por qué no deberíamos dejar que cada desarrollador tome sus propias decisiones? Debido a nuestra tendencia hacia el apego emocional. Mientras estamos en las trincheras trabajando en nuestro propio código contra la presión y los plazos no razonables, estamos en la mentalidad menos confiable para hacer esas llamadas de juicio.
Deberíamos someternos a herramientas para ayudar mantenemos nuestra disciplina.
Es similar a cómo los defensores de TDD se someten primero a la disciplina de escribir pruebas, en un conjunto formal de pasos. Lo que más valoramos es la disciplina y el resultado general del proceso, cuando estamos lo suficientemente nítidos para hacer ese análisis. ¡No instituimos ese tipo de proceso cuando nuestro código se rompe irremediablemente y no tenemos idea de por qué y solo estamos recurriendo a probar cambios aleatorios de código para ver si lo arreglan!
No. Si estamos siendo razonables, admitimos que el en general se cumple mejor cuando establecemos pautas razonables y luego seguimos la disciplina de adherirse a ellas.
La configuración es rey
Si a medida que se va a someter a sabiendas a este movimiento de dedos, usted (y su equipo, si corresponde) seguramente querrá decir algo, así que en qué reglas debe cumplir. Las opiniones arbitrarias e indiscutibles son las peores.
¿Recuerda los días de JSLint en que el 98% de las reglas fueron solo las opiniones de Crockford, y o usó la herramienta o no la usó? Él te advirtió en el README que te ibas a ofender y que deberías superarlo. Eso fue divertido, ¿verdad? (Algunos de ustedes aún pueden usar JSLint, ¡pero creo que deberían considerar pasar a una herramienta más moderna!)
Por eso ESLint es el rey de los linters en estos días. La filosofía es, básicamente, dejar que todo sea configurable. Deje que los desarrolladores y los equipos decidan democráticamente a qué opiniones quieren enviarse, por su propia disciplina y bien.
Eso no significa que cada desarrollador elija sus propias reglas. El propósito de las reglas es ajustar el código a un compromiso razonable, un "estándar centralizado", que tenga la mejor oportunidad de comunicarse más claramente con la mayoría de los desarrolladores del equipo.
Pero ninguna regla es 100% perfecta. Siempre hay casos de excepción. Por eso, tener la opción de deshabilitar o reconfigurar una regla con un comentario en línea, por ejemplo, no es solo un pequeño detalle, sino una característica crítica.
No quieres que un desarrollador tenga su propio ESLint local La configuración que anula las reglas mientras se confirma el código. Lo que usted quiere es que un desarrollador siga las reglas establecidas (¡preferido!) O para hacer una excepción a las reglas que sea clara y obvia en el punto donde se hace la excepción.
Idealmente, durante una revisión de código, esa excepción puede ser discutida y debatida y examinada. Tal vez estaba justificado, tal vez no lo estaba. Pero al menos era obvio, y al menos se podía discutir en primer lugar.
La configurabilidad de las herramientas es cómo hacemos que las herramientas funcionen para nosotros en lugar de que nosotros trabajemos para las herramientas.
Algunos prefieren las convenciones Enfoques basados en herramientas, donde las reglas están predeterminadas por lo que no hay discusión ni debate. Sé que funciona para algunos desarrolladores y para algunos equipos, pero no creo que sea un enfoque sostenible para aplicaciones amplias y generalizadas. En última instancia, una herramienta que es inflexible a las necesidades cambiantes del proyecto y el ADN de los desarrolladores que la usan, terminará cayendo en la oscuridad y finalmente se reemplazará.
Flechas apropiadas
Reconozco completamente mi uso de la palabra "apropiado" aquí va a revolver algunas plumas. "¿Quién es getify para decir qué es correcto y no?"
Recuerda, no estoy tratando de decirte lo que es correcto. Estoy tratando de hacer que acepten la idea de que las opiniones sobre => funciones de flecha son tan variadas como todos los matices de su sintaxis y uso, y que en última instancia, lo más apropiado es que algunos El conjunto de opiniones no importa cuáles sean, deben ser aplicables.
Aunque soy un gran fan de ESLint, me ha decepcionado la falta de apoyo de las reglas integradas de ESLint para controlar varios aspectos de => funciones de flecha. Hay hay a algunas reglas incorporadas, pero me frustra que parezcan centrarse principalmente en detalles estilísticos superficiales como el espacio en blanco .
Creo que hay una serie de aspectos que pueden dificultar la legibilidad de la función de flecha => problemas que van más allá de lo que puede controlar el actual conjunto de reglas de ESLint. pregunté alrededor de en twitter y parece que de las muchas respuestas que mucha gente tiene opiniones sobre esto.
La última interlocutora no solo le permitirá configurar reglas a su gusto. , pero construye tus propias reglas si faltara algo. ¡Por suerte, ESLint admite exactamente eso!
Así que decidí crear un complemento de ESLint para definir un conjunto adicional de reglas alrededor de => funciones de flecha: proper-arrows
. Antes de que explique algo al respecto, permítanme señalar: es un conjunto de reglas que se pueden activar o desactivar, y configurar, a su discreción. Si encuentra útil incluso un detalle de una regla, sería mejor usar la regla / complemento que no.
Estoy de acuerdo con que tenga sus propias opiniones sobre lo que hace => funciones de flecha apropiado. De hecho, ese es todo el punto. Si todos tenemos diferentes opiniones sobre las funciones de la flecha => deberíamos tener soporte de herramientas que nos permita elegir y configurar esas diferentes opiniones.
La filosofía de este complemento es que, para cada regla, cuando Si activa la regla, obtendrá todos sus modos de informe de forma predeterminada. Pero, por supuesto, no puede activar la regla, o puede activar la regla y luego configurar sus modos como mejor le parezca. Pero no quiero que tengas que ir a la caza de reglas / modos para activar, donde su oscuridad les impide siquiera ser considerados. Entonces todo viene por regla.
La única excepción aquí es que por defecto, todas las reglas ignoran trivial => funciones de flecha como ( ) => {} x => x etc. Si desea que se verifiquen, por regla tiene que activar esa comprobación con la opción {"trivial": true} .
Reglas de flechas apropiadas
Entonces, ¿qué reglas ¿están provistos? Aquí hay un extracto de de la descripción general del proyecto :
"params": controla las definiciones de=>parámetros de la función de flecha, como prohibir parámetros no utilizados, prohibir parámetros cortos / no emergentes nombres, etc."nombre": requiere que=>las funciones de flecha solo se usen en posiciones donde reciben un nombre inferido (es decir, asignado a una variable o propiedad, etc.), para evitar la mala capacidad de lectura / depuración de las expresiones de funciones anónimas."where": restringe where en la estructura del programa=>se pueden usar las funciones de flecha: prohibirlas en el nivel superior / global alcance, propiedades de objeto,declaraciones de exportaciónetc."return": restringe el tipo de valor de retorno conciso para=>funciones de flecha, como la prohibición de objetos conciso literal devoluciones (x => ({x})), prohibiendo devoluciones concisas de condiciona l / expresiones ternarias (x => x? y: z), etc."this": requiere / no permite=>funciones de flecha usando unaesta referenciaen la= >función de flecha en sí misma o en una función de flecha anidada=>. Esta regla puede prohibir opcionalmenteestas funciones de flechaque contienen=>del ámbito global.
Recuerde, cada regla tiene varios modos para configurar, por lo que nada de esto es todo o -nada. Elija lo que funciona para usted.
Como una ilustración de lo que las reglas de proper-arrows pueden verificar, echemos un vistazo a la regla "return" específicamente a su [19659089] modo "secuencia" . Este modo se refiere a la expresión de retorno concisa de => . Las funciones de flecha son una secuencia separada por comas como esta:
var myfunc = (x, y) => (x = 3, y = foo (x + 1), [x,y]);
Las secuencias se usan normalmente en => función concisa de flecha devuelve a la cadena varias declaraciones (expresión), sin necesidad de usar una cuerpo de función delimitado completo {..} y una declaración explícita return .
Algunos pueden amar este estilo, ¡está bien! – pero mucha gente piensa que favorece la codificación de estilo terso inteligente sobre la legibilidad, y preferiría en cambio:
var fn2 = (x, y) => {x = 3; y = foo (x + 1); retorno [x,y]; };
Observa que todavía es una función de flecha => y que ni siquiera son muchos otros caracteres. Pero es más claro que hay tres declaraciones separadas en este cuerpo de función.
Aún mejor:
var fn2 = (x, y) => {
x = 3;
y = foo (x + 1);
retorno [x,y];
};
Para ser claros, las reglas de proper-arrows no imponen diferencias de estilo triviales como espacios en blanco / sangría. Hay otras reglas (incorporadas) si desea hacer cumplir esos requisitos. proper-arrows se enfoca en lo que considero aspectos más sustanciales de => definición de la función.
Resumen conciso
Usted y yo casi no estamos de acuerdo en qué hace que sea bueno, correcto => estilo de función de flecha. Eso es bueno y saludable.
Mi objetivo aquí es doble:
- Convencerte de que las opiniones sobre esto varían y eso está bien.
- Te permite hacer y hacer valer tus propias opiniones (o el consenso del equipo) con herramientas configurables.
Realmente no hay nada que ganar al discutir sobre las reglas basadas en la opinión. Toma las que te gustan, olvida las que no.
Espero que eches un vistazo a proper-arrows y veas si hay algo allí que puedas usar para asegurarte. Las funciones de flecha => son la mejor forma posible, pueden estar en su base de código.
Y si faltan en el complemento algunas reglas que ayudarían a definir más flechas apropiadas por favor ¡Presente un problema y podemos discutir ! ¡Es completamente plausible que podamos agregar esa regla / modo, incluso si personalmente planeo mantenerla apagada!
No odio => funciones de flecha, y tú tampoco deberías. Simplemente odio el debate desinformado e indisciplinado. ¡Adoptemos herramientas más inteligentes y más configurables y pasemos a temas más importantes!
Acerca de Kyle Simpson
Kyle Simpson es un evangelista web abierto, apasionado de todo lo relacionado con JavaScript. Es un autor, instructor de talleres, orador técnico y colaborador / líder de OSS.
No comments:
Post a Comment