Si mi equipo tiene poca habilidad, ¿debería reducir la habilidad de mi código? [cerrado]

Por ejemplo, hay un fragmento común en JS para obtener un valor predeterminado:

function f(x) {
    x = x || 'default_value';
}

Todos los miembros de mi equipo no entienden fácilmente este tipo de fragmento, ya que su nivel de JS es bajo.

¿No debería usar este truco entonces? Hace que el código sea menos legible por los pares, pero más legible que el siguiente según cualquier desarrollador de JS:

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

Claro, si uso este truco y un colega lo ve, entonces pueden aprender algo. Pero el caso es que a menudo ven esto como "tratando de ser inteligente".

Entonces, ¿debería bajar el nivel de mi código si mis compañeros de equipo tienen un nivel más bajo que yo?

Ok, aquí va mi opinión sobre este tema grande y complicado.

Pros para mantener su estilo de codificación:

• Cosas como x = x || 10son idiomáticas en el desarrollo de JavaScript y ofrecen una forma de coherencia entre su código y el código de recursos externos que utiliza.
• Un nivel más alto de código suele ser más expresivo, sabes lo que obtienes y es más fácil de leer en profesionales altamente capacitados.
• Disfrutarás más de tu trabajo. Personalmente valoro crear código bonito. Creo que me da mucha satisfacción en mi trabajo.
• En general, crea un estilo más legible. Respetar las expresiones idiomáticas del idioma puede ser muy valioso; a menudo son expresiones idiomáticas por una razón.

Contras para mantener su estilo de codificación:

• Será más difícil para los programadores de nivel inferior mantenerse al día. Estas son a menudo las personas que mantienen su código y las que realmente tendrán que leer lo que usted escribe.
• Los mantenedores de código, a menudo, el código JavaScript proviene de otros idiomas. Sus programadores pueden ser competentes en Java o C #, pero no entienden cómo y cuándo JavaScript difiere exactamente. Estos puntos a menudo son idiomáticos: una expresión de función invocada inmediatamente (IIFE) es un ejemplo de tal construcción.

Mi opinión personal

No debe disminuir la habilidad de su código. Debe aspirar a escribir código que sea expresivo, claro y conciso. Si tiene dudas sobre el nivel de su equipo, infórmeles . Las personas están más que dispuestas a aprender de lo que piensas, y están dispuestas a adaptar nuevas construcciones cuando están convencidas de que son mejores.

Si piensan que 'solo estás siendo inteligente', intenta argumentar tu punto. Esté dispuesto a admitir que a veces se equivoca, y pase lo que pase, trate de mantener los estilos consistentes en todo su entorno de trabajo. Hacerlo ayudará a evitar la hostilidad.

Lo más importante es mantenerse constante.

El código de un equipo debe escribirse como si una persona lo codificara. Usted absolutamente tiene que ponerse de acuerdo sobre las directrices de codificación. Debe cumplir con esas pautas. Si las pautas de codificación especifican que la lectura de parámetros opcionales se debe hacer de la manera "menos inteligente", entonces esa es la forma.

Comenta bien

¿Deberías bajar la habilidad de tu código? No necesariamente, pero definitivamente debes elevar la habilidad de tus comentarios . Asegúrese de incluir buenos comentarios en su código, especialmente alrededor de las secciones que considere más complicadas. No use tantos comentarios que el código se vuelva difícil de seguir, pero asegúrese de aclarar el propósito de cada sección.

La realidad es que ser un poco más detallado con los comentarios puede ser útil con los miembros del equipo menos calificados, pero aquellos con la habilidad más baja los ignoran, especialmente si hay demasiados, así que no exagere.

¿Una cuestión de estilo?

El ejemplo que proporcionó es algo básico, pero también bastante estilístico. Un comentario sobre cada variable por defecto sería bastante tedioso de mantener y leer. En cambio, los atajos estilísticos o repetidos o patrones de código probablemente deberían establecerse como un estándar. Si cree que algo como esa forma de incumplimiento de parámetros debería ser entendido por todos y utilizado cada vez, escriba estas ideas y llévelas al líder de su equipo. Es posible que todo lo que se necesite para enseñar a sus compañeros de equipo sea una simple reunión en la que discuta los estándares que propuso.

Como ya dijo otra respuesta, manténgalo consistente .

Enseñar a un hombre a pescar ...

Enseñar a tus compañeros de equipo es probablemente la mejor manera de ayudar a todos los involucrados. Deje en claro que si alguien tiene una pregunta sobre un código con su nombre en el registro de confirmación o las marcas de tiempo, no dude en preguntarle al respecto. Si su equipo tiene revisiones de código, esta es una gran oportunidad para explicar cualquier código bien comentado posiblemente confuso (ejem) a sus compañeros de equipo. Si su equipo no tiene revisiones de código, ¿por qué no? ¡Hazlo!

Sin embargo, debes tener cuidado. Es posible que no siempre esté cerca para enseñar a la gente e incluso puede olvidar lo que originalmente estaba tratando de hacer en una sección de código determinada.

Trucos "inteligentes"

Tener en mente las habilidades de sus compañeros de equipo es definitivamente importante, pero escribir código que se pueda mantener a menudo significa no usar atajos arcanos a problemas que podrían tener soluciones más comunes. Esto es importante incluso cuando tus compañeros de equipo son inteligentes. No desea hacer que el código tarde demasiado en captar o tener efectos secundarios sutiles pero importantes que podrían perderse. En general, es mejor evitar los trucos "inteligentes" cuando existen alternativas adecuadas. Nunca se sabe quién podría tener que mantener el código en el futuro, a menudo las versiones anteriores de nosotros mismos no recordarán los detalles o las razones de estos trucos.

Si encuentra que debe implementar un truco inteligente, al menos siga el siguiente consejo ...

BESO

En caso de duda, manténgalo simple . Si el código es simple o no, no necesariamente corresponde a la habilidad del programador como podría pensar. De hecho, algunas de las soluciones más brillantes para un problema son las más simples, y algunas de las soluciones más complicadas terminan en TheDailyWTF . Mantener su código simple y conciso puede hacer que algunas de las decisiones más inteligentes pero posiblemente contra-intuitivas sean más fáciles de entender.

Parece haber una gran aversión a crear una función en JS. Esta aversión hace que las personas traten de ser inteligentes y usen trucos ridículos solo para mantener las cosas en una línea como lo hubiera sido una llamada de función. Por supuesto, el nombre de la función en una llamada también actúa como documentación adicional. No podemos adjuntar un comentario a una expresión engañosa porque entonces sería contraproducente hacerlo, así que simplemente lo llamamos "js idiom" y de repente es comprensible.

Javascript es extremadamente accesible, la mayoría de las personas no comen especificaciones para el desayuno como nosotros. Por lo tanto, nunca entenderán cuáles son las suposiciones ocultas y los casos extremos de un idioma.

x = x || 'default_value';

El Joe promedio no entenderá esto o ha memorizado que es el idioma para el valor predeterminado. Ambos son dañinos, de hecho, el último es aún más dañino. Él no entenderá los supuestos y los casos extremos aquí. No le importará leer la especificación y comprenderla nunca.

Cuando miro a ese código que ver "si es nullo undefined, luego otra vez en este valor por defecto. A pesar de que también tratará de manera implícita +0, -0, NaN, false, y ""los valores no adecuados. Voy a tener que recordar que 3 meses a partir de ahora cuando que las necesidades cambiar. Probablemente lo olvidaré ".

La suposición implícita es extremadamente probable que cause un error en el futuro y cuando su base de código está llena de trucos como este, entonces no hay posibilidad de que los tenga en su cabeza cada vez que piense en lo que afectará una modificación. Y esto es para el "JS pro", el Joe promedio habría escrito el error, incluso si los requisitos fueran aceptar un valor falso para empezar.

Su nuevo fragmento tiene una sintaxis más familiar pero aún tiene el problema anterior.

Puedes ir con:

function f(x) {
    x = valueOrDefault(x, "default_value");
}

Ahora puede tener una lógica muy compleja para manejar los casos extremos y el código del cliente todavía se ve hermoso y legible.

Ahora, ¿cómo se diferencia entre la función de lenguaje avanzado como pasar una función como argumento o un truco inteligente como || "default"?

Los trucos inteligentes siempre funcionan bajo algunos supuestos ocultos que podrían ignorarse cuando se creó el código inicialmente. Nunca tendré que modificar un IIFE a otra cosa porque un requisito cambió, siempre estará allí. Tal vez en 2020 cuando pueda usar módulos reales, pero sí.

| 0o la versión de culto de carga ~~numutilizada para pisos asume límites enteros positivos y con signo de 32 bits.

|| "default" asume que todos los valores falsos son iguales a no pasar un argumento en absoluto.

Y así.

No debe disminuir su habilidad de programación, pero es posible que deba ajustar la forma en que escribe el código. El objetivo, casi sobre todo, es dejar claro su código a las personas que deben leerlo y mantenerlo.

Desafortunadamente, puede ser una cuestión de juicio si un estilo en particular es "inteligente" o simplemente un uso avanzado. El código en la pregunta es un buen ejemplo de esto: su solución no es necesariamente mejor que la otra. Algunos argumentarán que sí, otros no estarán de acuerdo. Dado que ambas soluciones tienen efectivamente el mismo rendimiento de tiempo de ejecución (léase: el usuario nunca sabrá la diferencia), elija el estilo con el que el equipo en general se sienta más cómodo.

En algunos casos, debe enseñarles mejores formas de codificar, pero en otros debe comprometerse en aras de la claridad.

Puede que esto ya se haya dicho en otra respuesta, pero me gustaría responder a esta pregunta mis propias órdenes.

Directriz general

Cuando trabajas en un equipo, no eres el público objetivo de un código. Tu audiencia son los desarrolladores de tu equipo. No escriba código que no puedan entender sin una buena razón.

1. A menos que exista un inconveniente específico, todo el código debe escribirse siguiendo un patrón o directriz específico que permita un fácil mantenimiento por parte de los desarrolladores que lo mantendrán. (Una advertencia: seguir malos patrones solo porque están actualmente en la base del código es una práctica terrible).
2. Si puede encontrar una buena razón para usar un idioma específico del idioma que el público objetivo no pueda leer fácilmente, agregue un comentario. Si encuentra que necesita agregar un comentario a cada línea, puede reescribir su código para que su audiencia pueda leerlo mejor. No me parece valioso ser idiomático por ser idiomático.

Ejemplo especifico

Tenemos una gran cantidad de scripts perl en nuestra base de código. Por lo general, solo usamos perl para operaciones muy simples y la gran mayoría del código está escrito por desarrolladores de Java, por lo que tiene un estilo muy similar a Java. Tenemos un conjunto de scripts de perl y un marco que fue escrito por un 'perl guru' que desde entonces dejó nuestra empresa. Este código contiene muchos de los modismos perl más oscuros y ninguno de nuestros desarrolladores, incluido yo mismo, puede leer este código perl sin un esfuerzo extendido. A menudo lo maldecimos por eso. :)

Si escribe un buen código pero cree que sus colegas actuales o futuros pueden tener dificultades para seguirlo, debe agregar un breve comentario para explicarlo.

De esa manera, podría enseñarles algo sin insultar su inteligencia individual o avergonzar a nadie en una discusión grupal.

No llamaría a tu ejemplo un truco, sino idiomático. Si debe usarlo, en mi humilde opinión, no depende tanto del nivel actual de su equipo, sino si (al menos algunos de) sus compañeros de equipo están dispuestos a aprender algunas nuevas expresiones idiomáticas. Por supuesto, debe discutir este tema con ellos y no imponerles este estilo. Y no debe pedirles que aprendan cada día 5 cosas nuevas o "trucos". Pero, sinceramente, si solo tienes compañeros de equipo que no están dispuestos a aprender algo nuevo, incluso si es tan simple y pequeño como este idioma, deberías considerar cambiarte a un equipo diferente.

Al leer esta pregunta y las respuestas y discusiones posteriores parece haber dos puntos. El primero: ¿está bien usar funciones de lenguaje avanzadas? El segundo: ¿cómo puedo hacer esto sin parecer que estoy presumiendo?

En el primer caso, tiene sentido usar mejoras y funciones avanzadas. Por ejemplo: en C # no tiene que usar expresiones Linq o Lambda, pero la mayoría de las personas lo hacen porque hace que el código sea más ordenado y fácil de entender, una vez que realmente sabe lo que está haciendo. Al principio solo se ve extraño.

La gente se acostumbra a los patrones y, en muchos casos, usa la forma establecida de hacer las cosas solo para hacer el trabajo. Soy tan culpable de esto como el próximo hombre. Todos tenemos plazos. ¡En algunos aspectos eres culpable de introducir nuevas ideas y nuevas formas de pensar! Esto llega al segundo punto y es aquí donde probablemente encuentres la mayor resistencia.

A la persona que usa el sitio web no le importa qué estilo se usa, lo único que le importa es si funciona. ¿Es rápido? Entonces, si no hay una ventaja de rendimiento en su camino, entonces no hay una manera correcta o incorrecta en el ejemplo que da. ¿Tu forma hace que el código sea más legible o no? Podría hacerlo una vez que sus colegas estén acostumbrados.

Entonces, ¿cómo se introducen estos cambios? Intente mantener conversaciones con sus colegas en este sentido: ¿sabía que esta función se puede escribir de esta manera? Las revisiones de código y la programación de pares pueden ser buenos momentos para permitir la 'polinización cruzada' de ideas. Es complicado para mí prescribir qué hacer porque no conozco el entorno en el que está trabajando. Me parece que algunos programadores pueden ser muy defensivos y resistentes al cambio. Nuevamente he sido culpable de esto. La mejor manera de trabajar con este tipo de programadores es pasar un tiempo aprendiendo qué los hace funcionar, conocer sus antecedentes y luego comparar y contrastar sus estilos y experiencias con los suyos. Lleva tiempo pero es un tiempo bien empleado. Si es posible, trate de alentarlos.

Simplemente no vayas a trabajar para Royal McBee Computer Corp entonces, porque quién puede decir que no eres el programador inexperto.

seguro, es genial escribir código que sea breve y breve y podría ser útil en un entorno javascript (bueno, hasta que alguien produzca un compilador js para descargar en los navegadores, pero esa es otra historia).

Sin embargo, lo importante es la capacidad de su código para sobrevivir los pocos minutos que le llevó escribirlo. Claro, es rápido y fácil y puedes dividirlo y seguir adelante, pero si tienes que volver a hacerlo años después, es cuando piensas "¿qué muppet escribió esto", y te das cuenta de que eras tú! (Lo he hecho, seguro que la mayoría de la gente también lo ha hecho ... culpo a los plazos excesivamente agresivos, honesto).

Esto es lo único importante a tener en cuenta, por lo que si bien diría que sí, vaya con ese operador en particular si funciona y está claro, y sus desarrolladores 'inexpertos' (aunque eso es despectivo para ellos, sé mucho de desarrolladores sin experiencia que conocen todos los operadores y trucos, ya que han memorizado varios tutoriales y referencias de páginas web, escriben el peor código a pesar de que conocen cada pequeño truco ... puede haber más que coincidencia)

De todos modos, si pudieras leer la historia de Mel , te darías cuenta de que los trucos no son lo mejor para poner ningún código, a pesar de que Mel era un verdadero programador de primer orden. Esto pone en tela de juicio cualquier argumento en el que alguien dice que puede escribir un buen código y todos los demás necesitan aprender más para mantenerse al día.

Bueno, para empezar eso me parece un JS básico.

Pero, en general, no deberías usar hacks inteligentes, parafraseando "la depuración es el doble de difícil que la programación. Si escribes un código lo más inteligente posible, entonces, por definición, no puedes depurarlo".

Eso no significa que deba evitar el código solo porque otros no lo entenderían; debe escribir el código de la manera más clara y consistente posible. Pero su criterio de claridad debe ser "¿Lo entenderé en la primera lectura en un año", no "¿Alguien puede entenderlo?".

Escriba de manera clara, que no tiene dificultades para comprender y deje que otros trabajen para aumentar sus habilidades; no se perjudique para salvar a otros de problemas hipotéticos.

Discutiría con mis compañeros de equipo qué tipo de estándares de codificación queremos tener, ya que esto se trata principalmente de cómo se debe hacer algo de docenas de maneras para nuestra base de código. Si hay un consenso, ese sería mi intento inicial de respuesta.

Si no lo hay, entonces probablemente consideraría qué tipo de estándar propuesto tiene sentido y comenzaría a ponerlo en práctica una vez que lo haya aprobado con la gerencia y parte del equipo. La idea aquí es asegurarme de que la administración esté de acuerdo con esta idea y que no me limite a hacer lo mío y obligar a todos los demás a tomarlo.

Consideraría esto más como la pregunta de qué tipo de estándares y prácticas tiene su equipo en lugar de solo el nivel de habilidad, ya que hay muchas formas de evaluar el código. Qué tan bien pueden mantenerlo otros es uno de esos criterios.

El problema es que desea una buena legibilidad de la fuente, pero la legibilidad está en los ojos del espectador.

Sugeriría que necesitamos mejores herramientas para resolver este problema. Nada complejo, fíjate, hemos tenido la tecnología para hacerlo por más de 50 años. Incluya un analizador en el editor y haga que el editor guarde la fuente en forma de sexps (sí, al igual que lisp). Luego se lee la fuente, el editor la descompone en sintáctico y tipográfico (ya sabes, espacios, tabulaciones, comas), forma que el usuario prefiere.

De esta manera, puede escribir y leer x = x || 10y otros programadores lo leerán como

if (0 == x) { x = 10;}

emacs tiene todas las piezas para hacerlo fácilmente.

En lugar de simplificar el código, ¿por qué no mejorar la calidad del equipo? La capacitación, el entrenamiento, la educación y las prácticas mejoradas de contratación pueden hacer mucho para garantizar la mejora continua.
El estatismo, la descomposición del código, negarse a mejorar e innovar porque alguien no quiere trabajar en la superación personal solo causa problemas en el futuro, y más temprano que tarde.

Por supuesto, en el caso específico que muestra, solo está tratando de ser inteligente y escribir deliberadamente código ofuscado, lo cual nunca es una buena idea. El código debe ser, ante todo, legible, fácilmente comprensible, no escrito para mostrar lo inteligente que es crear algo en la menor cantidad de declaraciones posibles (salvo casos especiales, como cuando más declaraciones conducirían a un rendimiento inaceptablemente pobre, en cuyo caso se llaman comentarios copiosos para).