La importancia del triple igual (===) en JavaScript, resumida en una imagen

Quienes vengan de lenguajes de programación donde el operador comparación es un doble igual (==) pueden caer en la tentación de seguir usándolo en JavaScript. Y , ¿por qué no, si está definido y parece significar lo mismo? Realmente el doble igual en JavaScript intenta realizar una serie de conversiones entre tipos que a veces pueden venir bien, y ser la causa de frustantes bugs en muchas otras. Así que mejor tener claro qué ocurre cuando escribes a==b:

JavaScript_double_equal

Tabla de verdad de a==b para distintos valores de “a” y “b”.

 

La solución si queréis un operador igualdad estricto es usar el triple igual (===). Leed más aquí.

 

Fuente: http://dorey.github.io/JavaScript-Equality-Table/

Publicado en Programación Etiquetado con:
  • Ñbrevu

    Razón nº 23782967839041891287657568 por la que prefiero los lenguajes sanos. Y con tipado estático y fuerte (es decir, donde la mayoría de las comparaciones de la tabla no es que resulten en “false”, es que estarían prohibidas y el compilador te avisaría).

    • jlblanco

      Amén. Sabes que soy de tu misma secta de opinión: la de los que tenemos razón 😛

      Un abrazo tío!

    • jafma

      Jó, el sistema éste de publicación de comentarios de disqus es un poco follón y se me ha comido el mío. Bueno, decía que yo soy también de la secta, que me reafirmo en ser de la secta tras rascar un poco en el clamor popular a favor de python, y que hay más lenguajes de programación de esos fáciles fáciles para todo el mundo y que por tanto son de lo más guarros en los que pasa eso del doble igual, como PHP.

      • Ñbrevu

        PHP es quizá el peor lenguaje con el que he trabajado, es peor aún que Javascript. Todavía me acuerdo de la primera vez que me encontré al T_PAAMAYIM_NEKUDOTAYIM… y lo de Python lo considero una causa perdida, no lo voy a entender jamás, pero el hecho es que a muchísima gente le encanta. En el fondo entiendo algunas de las ventajas (aunque no sean de mi estilo), pero desde el momento en que le quitas el tipado estático, para mí es NO, es que se pierden demasiadas cosas. A cada cual lo suyo, supongo.

        He trabajado (por contar sólo lo que he hecho laboralmente, no académicamente o por mi cuenta) en sistemas grandes hechos con C++, PHP y Java, y en cosas un poco menos grandes con esos lenguajes y con Matlab, Flex, Javascript/Coffeescript y Python, y en general, cuanto más trabajo con los dos tipos de lenguajes, más claro tengo que los tipos son un invento necesario, tanto más cuanto mayor es el proyecto. El argumento habitual que se da es que los tests unitarios ya cubren las ventajas del tipado estático, pero 1) no es verdad, y 2) los tests no son exclusivos de los lenguajes sin tipos ni mucho menos.

        Ojo, que para mí no es una cuestión de que los lenguajes sean más fáciles o más difíciles, que está muy bien que haya cosas más simples para que la gente aprenda desde cero (yo por ejemplo aprendí con Div2 y un poco de Basic), pero creo que el eje simple-complicado no es el mismo que el eje guarro-limpio.

        • Guest

          Es que hay una regla muy clara: la programación, profesional y con
          garantías, nunca, nunca, nunca es fácil. El tiempo y el esfuerzo hay que
          dedicárselo seguro, así que, o se lo dedicas tratando de hacer mejor
          las cosas y comiéndote el tarro al principio (ayudado, por ejemplo, de
          un lenguaje de programación y herramientas de desarrollo que te exijan
          cumplir buenas prácticas), o te lo dan todo mascado al principio y luego
          lo sufres al final cuando tengas que mantener/extender/mejorar lo ya
          hecho. En mi opinión, lo último acumula tantas cosas por hacer que no se
          hicieron cuando debieron, que se convierte fácilmente en un infierno,
          salvo cuando uno hace programitas de juguete y sin requisitos de
          calidad.

          Respecto al python, yo tampoco entiendo nada: un
          lenguaje claramente hecho a base de parches incrementales, en el que
          conviven cosas procedurales con orientación a objeto casi sin ton ni
          son, y que te venden como el más legible del mundo (!?). Pues será
          legible, como el esperanto, pero no veas qué dolor cuando tengas que
          mantener una clase en cuyos elementos no puedes especificar limitaciones
          de privacidad…

        • jafma

          Hay una regla muy clara: la programación, profesional y con garantías, nunca, nunca, nunca es fácil. El tiempo y el esfuerzo hay que dedicárselo seguro, así que, o se lo dedicas tratando de hacer mejor las cosas y comiéndote el tarro al principio (ayudado, por ejemplo, de un lenguaje de programación y herramientas de desarrollo que te exijan cumplir buenas prácticas), o te lo dan todo mascado al principio y luego lo sufres al final cuando tengas que mantener/extender/mejorar lo ya hecho. En mi opinión, lo último acumula tantas cosas por hacer que no se hicieron cuando debieron, que se convierte fácilmente en un infierno, salvo cuando uno hace programitas de juguete y sin requisitos de calidad.

          Respecto al python, yo tampoco entiendo nada: un lenguaje claramente hecho a base de parches incrementales, en el que conviven cosas procedurales con orientación a objeto casi sin ton ni son, y que te venden como el más legible del mundo (!?). Pues será legible, como el esperanto, pero no veas qué dolor cuando tengas que mantener una clase en cuyos elementos no puedes especificar limitaciones de privacidad…