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

156

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?

Florian Margaine
fuente
42
Creo que esto se reduce a la pregunta "¿Deberías escribir código idiomático y obligar a la gente a ese nivel? ¿O escribir código no idiomático que explique todo explícitamente?"
53
¡No bajes el nivel de habilidad de tu código! Aprendí mucho leyendo el código de programadores más avanzados. Cree una cultura donde, si sus compañeros no entienden algo, se les aliente a preguntar (y aprender). Solo asegúrate de ser consistente.
Kosta Kontos
66
¿Tienes revisiones de código? Ese sería un excelente lugar para hacer preguntas sobre códigos como ese.
thegrinner
3
Parte de la habilidad de codificación es la claridad, teniendo en cuenta a su "audiencia". Parece que vale la pena enseñar este idioma en particular, pero ciertamente habrá casos en los que tendrá más sentido utilizar un estilo de codificación más transparente.
LarsH
3
¿Es solo decir quién piensa que el segundo ejemplo es de mejor calidad que el primer ejemplo ya que lo que se está haciendo es claro como el cristal? Parece que el segundo ejemplo es más legible que la versión breve que es el primer ejemplo. ¿No hay herramientas que tomarán automáticamente el código creado por humanos y lo optimizarán para Javascript? De acuerdo con mi experiencia con Javascript, el código que se ejecuta no tiene que ser lo suficientemente efectivo como sea posible.
Ramhound

Respuestas:

135

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.

Benjamin Gruenbaum
fuente
1
Sé que aprender es algo constante, pero ¿es realmente el trabajo de este desarrollador entrenar a sus compañeros de trabajo? Realmente debería ser trabajo de la gerencia encontrar la capacitación más adecuada para ellos.
corsiKa
8
@corsiKa Es poco probable que esos desarrolladores aprendan todas las idiosincrasias de un idioma a través de "capacitación remunerada" (es decir, el tipo de gestión de capacitación que enviaría al personal). Considero que es un lugar de trabajo enfermo cuando los compañeros de trabajo no aprenden unos de otros. No es como si el OP tuviera que darles capacitación en el aula. Las personas simplemente pueden hacer preguntas cuando están estancadas, y como se mencionó en un comentario anterior, las revisiones de código pueden ser buenas para compartir ese tipo de conocimiento.
MetalMikester
2
Sus compañeros de trabajo deberían aprender por su cuenta, a partir de los ejemplos establecidos por el OP (y otros). De lo contrario, nunca progresarán más allá de su conocimiento actual. El OP no debería tener que tomarse horas de cada día para entrenarlos personalmente, pero las revisiones de códigos y una sesión ocasional de bolsa marrón pueden ayudar a todos (bueno, a todos los que quieran aprender, claro ).
alroc
1
@corsiKa acordó que una revisión del código de un desarrollador senior no es una capacitación adecuada por sí misma, aunque puede ser una buena manera de identificar cosas que el desarrollador junior debería buscar más adelante.
Dan Lyons
2
@yms Bastante justo, ese es un punto de vista válido. Nunca discutí que la legibilidad es el rey. Tengo una fuerte objeción al uso de varios idiomas como si fueran el mismo idioma. Una objeción 'ganada' en cientos de horas de depuración. Si bien estoy completamente de acuerdo en que la legibilidad es el rey, creo que no puedes tratar los códigos en varios idiomas de manera similar. Además, creo que la mayor parte de la 'mala reputación' que tiene JavaScript se debe exactamente a eso. La gente espera que se comporte como en otro idioma, pero no es así. Estoy de acuerdo en que la legibilidad es de misión crítica. Mejor código siempre es más legible :)
Benjamin Gruenbaum
47

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.

Corion
fuente
10
El problema es que las características del lenguaje son vistas como "trucos ingeniosos", incluso cuando creo que claramente no lo son. ¿Alguna vez has visto un cierre? ¿Alguna vez has visto un IIFE? ¿Alguna vez has visto una referencia de función pasada como devolución de llamada? Esas son características del lenguaje que todo desarrollador JS experimentado conoce. Sin embargo, son "trucos inteligentes" para los desarrolladores de JS con menos experiencia.
Florian Margaine
1
@FlorianMargaine me parece que necesita trabajar para cambiar la terminología, es decir: estos no son "trucos inteligentes", son características más avanzadas del lenguaje ... 1 implica que su código no se entiende fácilmente / algo malo, 2 implica una oportunidad para aprender y mejorar 'mis' habilidades de codificación (¿cómo lograr que otros cambien su terminología? Comentarios, alentar preguntas, compartir artículos de código que explican cómo estas características son útiles, etc.)
Andrew Bickerton
3
Si alivia su dolor de cabeza, parte de la frustración puede ser que Javascript como lenguaje ... no tiene sentido. Tiene sentido para EE. UU., Las personas que publican aquí, porque lo hemos hecho durante mucho tiempo. Pero no importa cómo hayamos hecho que el lenguaje funcione "bien", para el ojo neutral simplemente no tiene sentido. En otra nota; lamentablemente, puede estar demostrando el valor de contratar desarrolladores experimentados , o preferiblemente, desarrolladores de 'cualquier idioma' con una alta disposición para aprender nuevos paradigmas.
Katana314
1
@FlorianMargaine También trabajo principalmente en JavaScript, sé el dolor que estás sintiendo. Me he acercado a esto tratando de educar a los compañeros de equipo. Los videos Crockford JavaScript ( 1 , 2 ) ayudan. No creo que esas cosas que enumeraste caigan bajo trucos "inteligentes", tus compañeros de equipo deberían aprenderlas, pero algunas de las cosas que haces con esas características del lenguaje podrían ser el tipo malo de "inteligente". Cómo convencer a su empresa para que contrate desarrolladores experimentados es probablemente otra cuestión completamente ...
Corion
2
Los comentarios no siempre son buenos. Leí "Clean Code" hace un tiempo y algunos puntos que hace sobre los comentarios son excelentes. Si siente la necesidad de escribir comentarios para explicar su código, existe una buena posibilidad de que el código esté mal escrito. Si el código fue más expresivo, un comentario es superfluo. Cada vez que esté a punto de escribir un comentario, deténgase por un momento para considerar si la refactorización podría ser una mejor opción. Si el código es expresivo, explicar su propósito se vuelve innecesario. Además, los comentarios pueden ser engañosos o simplemente incorrectos si se cambia el código pero los comentarios no se actualizan para que coincidan.
Pappa
34

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í.

Esailija
fuente
44
Te estás concentrando en un ejemplo. ¿Qué pasa con el uso de cosas como IIFE, cierres, referencias de funciones? Ese es el punto principal de mi pregunta.
Florian Margaine
1
@FlorianMargaine ¿No crees que lo aborde en la segunda parte lo suficientemente bien?
Esailija
3
Bueno, no dice nada sobre cómo manejar la situación en la que simplemente uso la "función de lenguaje avanzado", que los compañeros de equipo no entienden como "truco inteligente".
Florian Margaine
Me gusta esta respuesta +1, creo que pierde una gran parte de la pregunta, pero habla sobre otras partes y escenarios al respecto en profundidad y explica los problemas en otros desarrolladores de equipos que captan dichos conceptos por su cuenta sin la guía de leer su código.
Benjamin Gruenbaum
@FlorianMargaine, ¿quiere decir cómo manejar realmente una situación en la práctica en su lugar de trabajo donde está usando IIFE y alguien piensa que es un truco inteligente? Como expliqué, dado que no hay supuestos ocultos, una memorización como "las variables no serán globales" funcionará bien para el promedio.
Esailija
23

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.

Bryan Oakley
fuente
+1. Ninguno de los ejemplos específicos que dio el OP es empíricamente mejor que el otro, son simplemente diferentes.
Ross Patterson
Muy buena respuesta @ Bryan-Oakley. Saludos
Andy K
7

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. :)

usuario606723
fuente
5

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.

DavidR
fuente
3

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.

Doc Brown
fuente
3

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.

Daniel Hollinrake
fuente
Si crees que sería más fácil para ti ejemplificar lo que quieres decir en un entorno C #, dudo que a OP no le importe, seguro que no. Esta pregunta no se trata de JavaScript :) Imagínese renunciar a parámetros opcionales, o lambdas en su código porque otros desarrolladores del equipo no lo entienden, ¿lo haría? Creo que plantea algunas ideas interesantes aquí, pero si deja de preocuparse por el idioma específico, puede escribirlo de una manera más convincente :)
Benjamin Gruenbaum
1
Trabajo principalmente con C #, así que ese fue el ejemplo que más me vino a la mente. Realmente haces un excelente punto, con respecto a si renunciaría a las características útiles del lenguaje solo porque otros no las conocen. La respuesta tendría que ser no, pero, por supuesto, lo difícil es lograr que otros vean las ventajas de esta nueva forma, que parece ser el principal problema de Florian.
Daniel Hollinrake
3

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.

gbjbaanb
fuente
1
No conozco a un solo programador que no haya regresado a su código (¡desde hace un mes!) Y haya dicho "quién diablos escribió esto". Siempre evolucionamos en estilo (al menos lo intentamos). En este caso específico , OP está escribiendo código estándar, no código WTFish. OP no está discutiendo escribir código "inteligente" o código "más corto para ser genial", es JS idiomático.
Benjamin Gruenbaum
2

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.

jmoreno
fuente
1

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.

JB King
fuente
1

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.

Pascal Bourguignon
fuente
1
En este caso, sabemos quiénes son los espectadores. Ellos son nuestros compañeros de trabajo. Creo que esa frase se usa normalmente cuando no conoces a tu audiencia.
dcaswell
-1

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).

jwenting
fuente
55
En este caso, no estoy siendo inteligente. Estoy escribiendo código idiomático para cualquier desarrollador experimentado. ¿Ves por qué estoy luchando ahora? :)
Florian Margaine
3
Su primer párrafo es perfecto, pero -1 porque su segundo párrafo está fuera de lugar. Es inexacto decir que este ejemplo es un intento deliberado de ser inteligente. En realidad, es muy claro y, lo que es más importante, es un estilo idiomático en el que muchos buenos desarrolladores de JavaScript están de acuerdo. No es el único idioma en javascript para los parámetros de función predeterminados, pero es común.
Ben Lee