9 lecciones de una revisión del código JavaScript

 

 

 

  • SmashingConf Nueva York 2024
  • Register!

  • Índice
    1. Introducción
    2. ¿Dónde puedo hacer que revisen mi código?
    3. ¿Cómo debo estructurar mis solicitudes de revisión?
    4. ¿Qué deberían proporcionar las revisiones de código?
    5. Revisiones de código colaborativo
    6. Lecciones de una revisión de código JavaScript
      1. Problema 1
      2. Problema 2
      3. Problema 3
      4. Problema 4
      5. Problema 5
      6. Problema 6
      7. Problema 7

    Revisar el código es una de las mejores técnicas para mejorar la calidad general de sus soluciones. En esta publicación, Addy Osmani analiza dónde revisar su código, cómo estructurar sus solicitudes y qué buscan los revisores.

     

    Antes de comenzar, me gustaría plantear una pregunta: ¿cuándo fue la última vez que le pediste a alguien que revisara tu código? Revisar el código es posiblemente la mejor técnica para mejorar la calidad general de sus soluciones, y si no la aprovecha activamente, se está perdiendo la oportunidad de identificar errores y escuchar sugerencias que podrían mejorar su código.

    Ninguno de nosotros escribe código 100% libre de errores todo el tiempo, así que no sienta que hay un estigma asociado a buscar ayuda. Algunos de los desarrolladores más experimentados de nuestra industria, desde autores de marcos hasta desarrolladores de navegadores, solicitan periódicamente revisiones de su código a otros; Preguntar si algo se puede modificar no debe considerarse en modo alguno embarazoso. Las revisiones son una técnica como cualquier otra y deben utilizarse siempre que sea posible.

    Hoy veremos dónde revisar su código, cómo estructurar sus solicitudes y qué buscan los revisores. Recientemente me pidieron que revisara un código para una nueva aplicación de JavaScript y pensé que me gustaría compartir algunos de mis comentarios, porque cubren algunos fundamentos de JavaScript que siempre es útil tener en cuenta.

     

    Introducción

    Revisar el código va de la mano con mantener estándares de codificación sólidos. Dicho esto, los estándares no suelen evitar errores lógicos o malentendidos sobre las peculiaridades de un lenguaje de programación, ya sea JavaScript, Ruby, Objective-C o cualquier otro. Incluso los desarrolladores más experimentados pueden cometer este tipo de errores, y revisar el código puede ser de gran ayuda para detectarlos.

    La primera reacción que la mayoría de nosotros tenemos ante las críticas es defendernos (o defender nuestro código) y tal vez contraatacar. Si bien la crítica puede ser un poco desmoralizante, considérela como una experiencia de aprendizaje que nos impulsa a hacerlo mejor y a mejorarnos a nosotros mismos; porque en muchos casos, una vez que nos hemos calmado, realmente lo hace.

    Recuerde también que nadie está obligado a proporcionar comentarios sobre su trabajo y, si los comentarios son realmente constructivos, agradezca el tiempo dedicado a ofrecer sus comentarios.

    Las reseñas nos permiten aprovechar la experiencia de otros y beneficiarnos de un segundo par de ojos. Y al final del día, son una oportunidad para que escribamos un mejor código. Si los aprovechamos es enteramente nuestra elección.

    ¿Dónde puedo hacer que revisen mi código?

    A menudo, la parte más difícil es encontrar un desarrollador experimentado en quien confíe para realizar la revisión. A continuación se muestran algunos lugares donde puede solicitar a otros que revisen su código (a veces también en otros idiomas).

    • JSMentors
      JSMentors es una lista de correo que analiza todo lo relacionado con JavaScript (incluido Harmony), y varios desarrolladores experimentados están en su panel de revisión (incluidos JD Dalton, Angus Croll y Nicholas Zakas). Es posible que estos mentores no siempre estén disponibles, pero hacen todo lo posible para brindar comentarios útiles y constructivos sobre el código que se envía. Si está buscando ayuda con un marco de JavaScript específico más allá de JavaScript básico, la mayoría de los marcos y bibliotecas tienen listas de correo o foros en los que puede publicar y que podrían brindar un nivel similar de asistencia.
    • freenode IRC
      Muchas salas de chat aquí están dedicadas tanto a discutir el lenguaje JavaScript como a solicitudes de ayuda o revisión. Las salas más populares obviamente tienen nombre, y #javascript es particularmente útil para solicitudes genéricas de JavaScript, mientras que canales como #jquery y #dojo son mejores para preguntas y solicitudes relacionadas con bibliotecas y marcos particulares.
    • Revisión de código (beta)
      Se le perdonará que confunda la Revisión de código con StackOverflow, pero en realidad es una herramienta subjetiva, de amplio espectro y muy útil para obtener una revisión del código por pares. Mientras estás en StackOverflow, puedes hacer la pregunta "¿Por qué mi código no funciona?", Code Review es más adecuado para preguntas como "¿Por qué mi código es tan feo?" Si aún tienes alguna duda sobre lo que ofrece, te recomiendo encarecidamente que consultes las preguntas frecuentes .
    • Twitter
      Esto puede parecer extraño, pero al menos la mitad del código que envío para revisión se realiza a través de las redes sociales. Las redes sociales funcionan mejor, por supuesto, si tu código es de código abierto, pero probarlas nunca está de más. Lo único que sugiero es asegurarse de que los desarrolladores a los que sigue e interactúa tienen experiencia; una revisión realizada por un desarrollador sin experiencia suficiente a veces puede ser peor que ninguna revisión, ¡así que tenga cuidado!
    • GitHub + reviewth.is
      Todos sabemos que GitHub proporciona una arquitectura excelente para revisar código. Viene con confirmaciones, comentarios de archivos y líneas, notificaciones de actualización, una manera fácil de rastrear bifurcaciones de gits y repositorios, y más. Lo único que falta es una forma de iniciar revisiones. Una herramienta llamada reviewth.is intenta rectificar esto brindándole un gancho posterior a la confirmación que ayuda a automatizar este proceso, de modo que los cambios que se publican en la naturaleza tengan una etiqueta hash #reviewthis clara y usted pueda etiquetar a los usuarios que desee. para revisar sus actualizaciones. Si muchos de sus colegas desarrollan en el mismo idioma que usted, esta configuración puede funcionar bien para revisiones de código obtenidas más cerca de casa. Un flujo de trabajo que funciona bien con esto (si está trabajando en un equipo o en un proyecto colaborativo) es realizar su propio trabajo en una rama temática en un repositorio y luego enviar solicitudes de extracción en esa rama. Los revisores examinarían los cambios y las confirmaciones y luego podrían hacer comentarios línea por línea y archivo por archivo. Luego, usted (el desarrollador) tomaría estos comentarios y haría una rebase destructiva en esa rama del tema, la volvería a enviar y permitiría que el ciclo de revisión se repitiera hasta que fusionarlos fuera aceptable.

    ¿Cómo debo estructurar mis solicitudes de revisión?

    Las siguientes son algunas pautas (basadas en la experiencia) sobre cómo estructurar sus solicitudes de revisión de código para aumentar las posibilidades de que sean aceptadas. Puede ser más liberal con ellos si el revisor está en su equipo; pero si el revisor es externo, esto podría ahorrarle algo de tiempo:

     

    • Aísle lo que le gustaría que se revise; asegurarse de que se pueda ejecutar, bifurcar y comentar fácilmente; Sea claro acerca de dónde cree que se podrían realizar mejoras; y, sobre todo, tener paciencia.
    • Haga que sea lo más fácil posible para el revisor ver, realizar demostraciones y cambiar su código.
    • No envíe un archivo ZIP de todo su sitio web o proyecto; muy pocas personas tienen tiempo para pasar por todo esto. La única situación en la que esto sería aceptable es si su código requiriera absolutamente pruebas locales.
    • En su lugar, aísle y reduzca lo que le gustaría que se revise en jsFiddle , en jsbin o en una esencia de GitHub . Esto permitirá al revisor bifurcar fácilmente lo que has proporcionado y mostrar cambios y comentarios sobre lo que se puede mejorar. Si prefiere una "diferencia" entre su trabajo y cualquier cambio que hayan recomendado, es posible que también le interese PasteBin , que lo admite.
    • De manera similar, no se limite a enviar un enlace a una página y pedirles que "Ver código fuente" para ver qué se puede mejorar. En sitios web con muchos scripts, esta tarea sería un desafío y reduciría las posibilidades de que un revisor acepte ayudar. Nadie quiere trabajar para encontrar lo que quiere que se revise.
    • Indique claramente dónde cree personalmente que se podría mejorar la implementación. Esto ayudará al revisor a identificar rápidamente lo que más le interesa que haya revisado y le ahorrará tiempo. Muchos revisores seguirán mirando otras partes del código que usted envió, pero al menos ayúdelos a priorizar.
    • Indique qué investigación (si la hay) ha realizado sobre técnicas para mejorar el código. Es muy posible que el revisor sugiera los mismos recursos, pero si sabe que usted ya los conoce, entonces podría ofrecerle sugerencias alternativas (que es lo que desea).
    • Si el inglés no es tu primer idioma, no hay nada de malo en decirlo. Cuando otros desarrolladores me informan de esto, sé si debo mantener el lenguaje técnico o simple en mi revisión.
    • Ser paciente . Algunas reseñas tardan varios días en llegar a mis manos y eso no tiene nada de malo. Otros desarrolladores suelen estar ocupados con otros proyectos y alguien que acepta programar una visita a su trabajo es amable. Sea paciente, no les envíe spam con recordatorios y sea comprensivo si se retrasan. Hacer esto a veces vale la pena, porque el revisor puede proporcionar comentarios aún más detallados cuando tiene más tiempo.

    ¿Qué deberían proporcionar las revisiones de código?

    Jonathan Betz, ex desarrollador de Google, dijo una vez que lo ideal sería que una revisión de código abordara seis cosas:

     

    1. Corrección
      ¿El código hace todo lo que dice?
    2. Complejidad
      ¿Logra sus objetivos de manera sencilla?
    3. Coherencia
      ¿Logra sus objetivos de manera consistente?
    4. Mantenibilidad
      ¿Podría otro miembro del equipo ampliar fácilmente el código con un nivel razonable de esfuerzo?
    5. Escalabilidad
      ¿El código está escrito de tal manera que funcione tanto para 100 usuarios como para 10 000? ¿Está optimizado?
    6. Estilo ¿
      Se adhiere el código a una guía de estilo particular (preferiblemente una acordada por el equipo si el proyecto es colaborativo)?

    Si bien estoy de acuerdo con esta lista, sería útil ampliarla a una guía de acción de lo que los revisores deberían intentar ofrecer prácticamente a los desarrolladores. Entonces, los revisores deben hacer lo siguiente:

    • Proporcione comentarios claros, demuestre conocimientos y comuníquese bien.
    • Señale las deficiencias en una implementación (sin ser demasiado crítico).
    • Indique por qué no se recomienda un enfoque en particular y, si es posible, consulte publicaciones de blog, esencias, especificaciones, páginas de MDN y pruebas jsPerf para respaldar la afirmación.
    • Sugiera soluciones alternativas, ya sea en un formato ejecutable por separado o integradas en el código mediante una bifurcación, para que el desarrollador pueda ver claramente qué hizo mal.
    • Concéntrese primero en las soluciones y luego en el estilo. Las sugerencias sobre estilo pueden aparecer más adelante en la revisión, pero aborde el problema fundamental lo más a fondo posible antes de prestarle atención.
    • Revisión más allá del alcance de lo solicitado. Esto queda totalmente a discreción del revisor, pero si noto problemas con otros aspectos de la implementación de un desarrollador, generalmente trato de asesorarlos sobre cómo esos también podrían mejorarse. Todavía no he recibido ninguna queja sobre esto, así que supongo que no es malo.

    Revisiones de código colaborativo

    Aunque una revisión por parte de un desarrollador puede funcionar bien, un enfoque alternativo es involucrar a más personas en el proceso. Esto tiene algunas ventajas distintivas, incluida la reducción de la carga de los revisores individuales y exponer a más personas a su implementación, lo que potencialmente podría generar más sugerencias de mejora. También permite filtrar y corregir los comentarios de un revisor si cometen un error.

     

    Para ayudar al grupo, es posible que desee emplear una herramienta colaborativa que permita a todos los revisores inspeccionar y comentar su código simultáneamente. Afortunadamente, vale la pena echarle un vistazo a algunos decentes:

    • Review Board
      Esta herramienta basada en la web está disponible de forma gratuita bajo la licencia del MIT. Se integra con Git, CVS, Mercurial, Subversion y varios otros sistemas de control de fuente. Review Board se puede instalar en cualquier servidor que ejecute Apache o lighttpd y es gratuito para uso personal y comercial.
    • Crucible
      Esta herramienta de la empresa australiana de software Atlassian también está basada en la Web. Está dirigido a la empresa y funciona mejor con equipos distribuidos. Crucible facilita tanto la revisión en vivo como los comentarios en vivo y, al igual que Review Board, se integra con una serie de herramientas de control de código fuente, incluidas Git y Subversion.
    • Rietveld
      Al igual que los otros dos, Rietveld también admite la revisión colaborativa, pero en realidad fue escrito por el creador de Python, Guido van Rossum. Está diseñado para ejecutarse en el servicio de nube de Google y se beneficia de la experiencia de Guido escribiendo Mondrian, la aplicación patentada que Google utiliza internamente para revisar su código.
    • Otros
      Varias otras opciones para la revisión colaborativa de código no se crearon para ese propósito. Estos incluyen CollabEdit (gratuito y basado en la Web) y, mi favorito personal, EtherPad (también gratuito y basado en la Web).

    Lecciones de una revisión de código JavaScript

    A la reseña. Salarios y Sueldos medios 2023

    Un desarrollador me escribió recientemente pidiéndome que revisara su código y le brindara algunas sugerencias útiles sobre cómo podrían mejorarlo. Si bien ciertamente no soy un experto en revisar código (no dejes que lo anterior te engañe), aquí están los problemas y las soluciones que propuse.

     

    Problema 1

    Problema: las funciones y los objetos se pasan como argumentos a otras funciones sin ninguna validación de tipo.

    Comentarios: La validación de tipos es un paso esencial para garantizar que esté trabajando solo con entradas del tipo deseado. Sin controles de desinfección implementados, corre el riesgo de que los usuarios pasen casi cualquier cosa (una cadena, una fecha, una matriz, etc.), lo que fácilmente podría dañar su aplicación si no la ha desarrollado de manera defensiva. Para las funciones, debe hacer lo siguiente como mínimo:

    1. Pruebe para garantizar que los argumentos que se pasan realmente existan,
    2. Realice una typeofverificación para evitar que la aplicación ejecute una entrada que no sea una función válida en absoluto.
    if (callback typeof callback === "function"){ /* rest of your logic */}else{ /* not a valid function */}

    Lamentablemente, una simple typeofcomprobación no es suficiente por sí sola. Como señala Angus Croll en su publicación " Arreglando el tipo de operador ", debes tener en cuenta una serie de problemas al typeofverificar si los estás usando para algo más que funciones.

    Por ejemplo, typeof nulldevuelve object, lo cual es técnicamente incorrecto. De hecho, cuando se aplica a cualquier tipo de objeto que no typeofsea una función, devuelve object, sin distinguir entre Array, o cualquier otra cosa.DateRegEx

    La solución es utilizar Object.prototype.toStringpara llamar a la propiedad interna subyacente de los objetos JavaScript conocida como [[Class]]propiedad de clase del objeto. Desafortunadamente, los objetos integrados especializados generalmente sobrescriben Object.prototype.toString, pero puedes forzarles la toStringfunción genérica:

    Object.prototype.toString.call([1,2,3]); //"[object Array]"

    También puede encontrar útil la función de Angus a continuación como una alternativa más confiable a typeof. Intente llamar betterTypeOf()a objetos, matrices y otros tipos para ver qué sucede.

    function betterTypeOf( input ){ return Object.prototype.toString.call(input).match(/^[objects(.*)]$/)[1];}

    Aquí, parseInt()se utiliza ciegamente para analizar un valor entero de la entrada del usuario, pero no se especifica ninguna base. Esto puede causar problemas.

    En JavaScript: The Good Parts , Douglas Crockford se refiere a parseInt()él como peligroso. Aunque probablemente sepa que pasarle un argumento de cadena devuelve un número entero, idealmente también debería especificar una base o base como segundo argumento; de lo contrario, podría devolver un resultado inesperado. Tomemos el siguiente ejemplo:

    parseInt('20'); // returns what you expect, however…parseInt('020'); // returns 16parseInt('000020'); // returns 16parseInt('020', 10); // returns 20 as we've specified the base to use

    Te sorprendería saber cuántos desarrolladores omiten el segundo argumento, pero sucede con bastante regularidad. Recuerde que sus usuarios (si se les permite ingresar datos numéricos libremente) no necesariamente seguirán las convenciones numéricas estándar (¡porque están locos!). He visto el uso de 020, ,20y ;‘20muchas otras variaciones, así que haz lo mejor que puedas para analizar una gama de entradas lo más amplia posible. Los siguientes trucos de uso parseInt()son ocasionalmente mejores:

     

    Math.floor("020"); // returns 20Math.floor("0020"); //returns 20Number("020"); //returns 20Number("0020"); //returns 20+"020"; //returns 20

    Problema 2

    Problema: Las comprobaciones de que se cumplan las condiciones específicas del navegador se repiten en todo el código base (por ejemplo, detección de funciones, comprobaciones de funciones ES5 compatibles, etc.).

    Comentarios: Idealmente, su código base debería ser lo más SECO posible y existen algunas soluciones elegantes para este problema. Por ejemplo, podría beneficiarse del patrón de configuración de tiempo de carga aquí (también llamado bifurcación de tiempo de carga y tiempo de inicio). La idea básica es probar una condición solo una vez (cuando se carga la aplicación) y luego acceder al resultado de esa prueba para todas las comprobaciones posteriores. Este patrón se encuentra comúnmente en bibliotecas de JavaScript que se configuran en el momento de la carga para optimizarse para un navegador en particular.

    Este patrón podría implementarse de la siguiente manera:

    var tools = { addMethod: null, removeMethod: null};if(/* condition for native support */){ tools.addMethod = function(/* params */){ /* method logic */ }}else{ /* fallback - eg. for IE */ tools.addMethod = function(/* */){ /* method logic */ }}

    El siguiente ejemplo demuestra cómo se puede utilizar esto para normalizar la obtención de un XMLHttpRequestobjeto.

    var utils = { getXHR: null};if(window.XMLHttpRequest){ utils.getXHR = function(){ return new XMLHttpRequest; }}else if(window.ActiveXObject){ utils.getXHR = function(){ /* this has been simplified for example sakes */ return new ActiveXObject(’Microsoft.XMLHTTP’); }}

    Para dar un gran ejemplo, Stoyan Stefanov aplica esto para adjuntar y eliminar detectores de eventos en varios navegadores, en su libro JavaScript Patterns :

    var utils = { addListener: null, removeListener: null};// the implementationif (typeof window.addEventListener === ’function’) { utils.addListener = function ( el, type, fn ) { el.addEventListener(type, fn, false); }; utils.removeListener = function ( el, type, fn ) { el.removeEventListener(type, fn, false); };} else if (typeof document.attachEvent === ’function’) { // IE utils.addListener = function ( el, type, fn ) { el.attachEvent(’on’ + type, fn); }; utils.removeListener = function ( el, type, fn ) { el.detachEvent(’on’ + type, fn); };} else { // older browsers utils.addListener = function ( el, type, fn ) { el[’on’ + type] = fn; }; utils.removeListener = function ( el, type, fn ) { el[’on’ + type] = null; };}

    Problema 3

    Problema: El nativo Object.prototypese amplía periódicamente.

     

    Comentarios: La extensión de tipos nativos generalmente está mal vista, y pocas bases de código populares (si es que hay alguna) deberían atreverse a extenderlas Object.prototype. La realidad es que no existe una situación en la que sea absolutamente necesario extenderlo de esta manera. Además de romper las tablas de objetos como hash en JavaScript y aumentar la posibilidad de colisiones de nombres, generalmente se considera una mala práctica y modificarla solo debería ser un último recurso (esto es bastante diferente a extender sus propias propiedades personalizadas object ).

    Si por alguna razón terminas ampliando el objectprototipo, asegúrate de que el método no exista ya y documentalo para que el resto del equipo sepa por qué es necesario. Puede utilizar el siguiente ejemplo de código como guía:

    if(typeof Object.prototype.myMethod != ’function’){ Object.prototype.myMethod = function(){ //implem };}

    Juriy Zaytsev tiene una excelente publicación sobre cómo ampliar objetos nativos y host, que puede ser de interés.

    Problema 4

    Problema: parte del código bloquea en gran medida la página porque está esperando que se completen los procesos o que se carguen los datos antes de ejecutar nada más.

    Comentarios: El bloqueo de páginas genera una experiencia de usuario deficiente y existen varias formas de solucionarlo sin afectar la aplicación.

    Una solución es utilizar la “ejecución diferida” (mediante promesas y futuros). La idea básica con las promesas es que, en lugar de emitir solicitudes de bloqueo de recursos, inmediatamente se devuelve una promesa por un valor futuro que eventualmente se cumplirá. Esto le permite con bastante facilidad escribir lógica sin bloqueo que se puede ejecutar de forma asincrónica. Es común introducir devoluciones de llamada en esta ecuación que se ejecutan una vez que se completa la solicitud.

    Escribí una publicación relativamente completa sobre esto con Julian Aubourg, si estás interesado en hacerlo a través de jQuery, pero, por supuesto, también se puede implementar con JavaScript básico.

    Micro-framework Q ofrece una implementación de promesas y futuros compatible con CommonJS que es relativamente completa y se puede utilizar de la siguiente manera:

    /* define a promise-only delay function that resolves when a timeout completes */function delay(ms) { var deferred = Q.defer(); setTimeout(deferred.resolve, ms); return deferred.promise;}/* usage of Q with the 'when' pattern to execute a callback once delay fulfils the promise */Q.when(delay(500), function () { /* do stuff in the callback */});

    Si está buscando algo más básico que pueda leerse, aquí está la implementación de las promesas de Douglas Crockford:

    function make_promise() { var status = ’unresolved’, outcome, waiting = [], dreading = []; function vouch( deed, func ) { switch (status) { case ’unresolved’: (deed === ’fulfilled’ ? waiting : dreading).push(func); break; case deed: func(outcome); break; } }; function resolve( deed, value ) { if (status !== ’unresolved’) { throw new Error(’The promise has already been resolved:’ + status); } status = deed; outcome = value; (deed == ’fulfilled’ ? waiting : dreading).forEach(function (func) { try { func(outcome); } catch (ignore) {} }); waiting = null; dreading = null; }; return { when: function ( func ) { vouch(’fulfilled’, func); }, fail: function ( func ) { vouch(’smashed’, func); }, fulfill: function ( value ) { resolve(’fulfilled’, value); }, smash: function ( string ) { resolve(’smashed’, string); }, status: function () { return status; } };};

    Problema 5

    Problema: estás probando la igualdad numérica explícita de una propiedad usando el ==operador, pero probablemente deberías usar ===en su lugar

     

    Comentarios: Como quizás sepas o no, el ==operador de identidad en JavaScript es bastante liberal y considera que los valores son iguales incluso si son de tipos completamente diferentes. Esto se debe a que el operador fuerza una coerción de valores en un solo tipo (generalmente un número) antes de realizar cualquier comparación. Sin embargo, el ===operador no realizará esta conversión, por lo que si los dos valores que se comparan no son del mismo tipo, ===simplemente devolverá false.

    La razón por la que recomiendo considerar ===una comparación de tipos más específica (en este caso) es que ==se sabe que tiene varios errores y muchos desarrolladores lo consideran poco confiable.

    Quizás también le interese saber que en abstracciones del lenguaje, como CoffeeScript, el ==operador se descarta por completo en favor de ===lo oculto debido a la falta de confiabilidad del primero.

    En lugar de confiar en mi palabra, vea los ejemplos a continuación de comprobaciones booleanas de igualdad usando ==, algunas de las cuales dan como resultado resultados bastante inesperados.

    3 == "3" // true3 == "03" // true3 == "0003" // true3 == "+3" //true3 == [3] //true3 == (true+2) //true’ trn ’ == 0 //true"trn" == 0 //true"t" == 0 // true"tn" == 0 // true"tr" == 0 // true" " == 0 // true" t" == 0 // true" " == 0 // true" rn " == 0 //true

    La razón por la que se evalúan muchos de los resultados (extraños) en esta lista truees porque JavaScript es un lenguaje débilmente tipado: aplica coerción de tipos siempre que sea posible. Si está interesado en aprender más sobre por qué algunas de las expresiones anteriores se evalúan como true, consulte la guía ES5 anotada , cuyas explicaciones son bastante fascinantes.

    Volver a la reseña. Si está 100% seguro de que el usuario no puede interferir con los valores que se están comparando, entonces proceda a utilizar el ==operador con precaución. Sólo recuerda que eso ===cubre mejor tus bases en caso de una entrada inesperada.

    Problema 6

    Problema:length se utiliza una matriz sin caché en todos forlos bucles. Esto es particularmente malo porque lo estás usando al iterar a través de una HTMLCollection.

    He aquí un ejemplo:

    for( var i=0; imyArray.length;i++ ){ /* do stuff */}

    Comentarios: El problema con este enfoque (que todavía veo que varios desarrolladores usan) es que lengthse vuelve a acceder innecesariamente a la matriz en cada iteración del bucle. Esto puede ser muy lento, especialmente cuando se trabaja con colecciones HTML (en cuyo caso, almacenar en caché lengthpuede ser hasta 190 veces más rápido que acceder a ellas repetidamente, como menciona Nicholas C. Zakas en su libro JavaScript de alto rendimiento ). A continuación se muestran algunas opciones para almacenar en caché la matriz length.

    /* cached outside loop */var len = myArray.length;for ( var i = 0; i len; i++ ) {}/* cached inside loop */for ( var i = 0, len = myArray.length; i len; i++ ) {}/* cached outside loop using while */var len = myArray.length;while (len--) {}

    También está disponible una prueba jsPerf que compara los beneficios de rendimiento del almacenamiento en caché de la matriz lengthdentro y fuera del bucle, usando incrementos de prefijo, cuenta regresiva y más, si desea estudiar cuál funciona mejor.

    Problema 7

    Problema: jQuery $.each()se utiliza para iterar sobre objetos y matrices, en algunos casos mientras forse utiliza en otros.

    Comentarios: En jQuery, tenemos dos formas de iterar sin problemas sobre objetos y matrices. El genérico $.eachitera sobre ambos tipos, mientras que $.fn.each()itera específicamente sobre un objeto jQuery (donde se pueden empaquetar objetos estándar $()si desea usarlos con este último). Si bien el nivel inferior <






    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    9 lecciones de una revisión del código JavaScript

    9 lecciones de una revisión del código JavaScript

    SmashingConf Nueva York 2024 Register! Índice Introducción

    programar

    es

    https://aprendeprogramando.es/static/images/programar-9-lecciones-de-una-revision-del-codigo-javascript-784-0.jpg

    2024-05-20

     

    9 lecciones de una revisión del código JavaScript
    9 lecciones de una revisión del código JavaScript

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20