El error “++ inesperado” en jslint [duplicate]

9 minutos de lectura

avatar de usuario
DesvKdg

Qué es ¿La mejor práctica para eso entonces?

Jslint explica que “agrega confusión”. no lo veo la verdad…

EDITAR: El código, según lo solicitado:

  var all,l,elements,e;
  all = inElement.getElementsByTagName('*');
  l = all.length;
  elements = [];
  for (e = 0; e < l; (e++))
  {
    if (findIn)
    {
        if (all[e].className.indexOf(className) > 0)
        {
            elements[elements.length] = all[e];
        }
    } else {
        if (all[e].className === className)
        {
            elements[elements.length] = all[e];
        }
    }
  }

  • @WebDevHobo Eso marca “No permitir ++ y --“. Por supuesto que se va a quejar. 😉

    – Samir Talwar

    11 de junio de 2010 a las 13:58

  • Este debe ser el más tonto verifique en JSLint. ¿En serio? cuando tiene ++ o -- ¿Ha causado alguna vez a un programador alguna confusión? Me encanta JSLint, pero VAMOS.

    – Esteban

    2 de noviembre de 2010 a las 15:12


  • @blackrocky ¿Se supone que eso es menos confuso que i–? 🙂

    – Igor Jerosimić

    11 de diciembre de 2011 a las 21:32

  • En mi opinión, la aplicación de } else { es la cosa más tonta en JSLint.

    – Almo

    14 de junio de 2012 a las 15:21


  • Line 26 // WARNING: JSLint will hurt your feelings.

    – yuan

    1 de julio de 2013 a las 11:43


avatar de usuario
unomi

La mejor práctica desde hace mucho tiempo: Usar i += 1 en cambio, siguiendo el consejo de jslint.

En cuanto a por qué es una mejor práctica que ++según Crockford:

el incremento ++ y decrementar -- Los operadores hacen posible escribir en un estilo extremadamente conciso. En lenguajes como C, hicieron posible escribir frases ingeniosas que: for (p = src, q = dest; !*p; p++, q++) *q = *p; La mayoría de los errores de desbordamiento del búfer que crearon terribles vulnerabilidades de seguridad se debieron a un código como este. En mi propia práctica, observé que cuando usaba ++ y --, mi código tendía a ser demasiado estricto, demasiado engañoso, demasiado críptico. Entonces, por una cuestión de disciplina, no los uso más.

Editar: comentario incluido de Nope ya que esta respuesta continúa recibiendo visitas. Continúe votando su comentario también 🙂

  • Esto realmente no explica el bit de confusión ‘agrega’. @ samir-talwar agrega una explicación.

    –Matt Clarkson

    12 de septiembre de 2011 a las 13:44

  • @MattClarkson: Según Crockford: el incremento ++ y decrementar -- Los operadores hacen posible escribir en un estilo extremadamente conciso. En lenguajes como C, hicieron posible escribir frases ingeniosas que: for (p = src, q = dest; !*p; p++, q++) *q = *p; La mayoría de los errores de desbordamiento del búfer que crearon terribles vulnerabilidades de seguridad se debieron a un código como este. En mi propia práctica, observé que cuando usaba ++ y --, mi código tendía a ser demasiado estricto, demasiado engañoso, demasiado críptico. Entonces, por una cuestión de disciplina, no los uso más.

    – No

    28 de marzo de 2013 a las 9:56

  • @MattClarkson: En for su uso es claro y no se produce confusión, pero el uso puede ser críptico y confisante en otras circunstancias. Supongo que para evitar escribir código críptico en otros segmentos de código más complejos, es mejor evitarlo por completo. Es solo una recomendación y puede ser ignorada 🙂

    – No

    28 de marzo de 2013 a las 10:00


  • @FrançoisWahl Gracias por el Crockford explicacion

    –Matt Clarkson

    28 de marzo de 2013 a las 12:03

  • Simplemente ignóralo; JSLint a veces tiene interpretaciones muy extrañas sobre las cosas… Útil en ocasiones pero molesto en otras ocasiones.

    – Lorenzo

    14/01/2014 a las 13:45

Solo agrega /*jslint plusplus: true */ delante de su archivo javascript.

  • Eso es genial, ¡muchas gracias por esta información!

    – Mathias Bader

    7 noviembre 2013 a las 10:50

  • Aunque a partir del 9 de julio de 2014, Crockford advierte que esta quitando esa opcionjunto con varios otros. In the next edition of JSLint I will be removing several options... ass, closure, continue, eqeq, newcap, nomen, plusplus, sloppy, stupid, sub.

    – rufián

    15/09/2014 a las 15:03

  • o "plusplus" : false en .jshintrc

    – usuario3751385

    15 de mayo de 2015 a las 9:10


avatar de usuario
Sean Kinsey

Para evitar confusiones y posibles problemas al usar minificadores, siempre coloque paréntesis alrededor del operador y su operando cuando se usa junto con el mismo (+ o -).

var i = 0, j = 0;
alert(i++ +j);

Esto agrega i y j (e incrementa i como un efecto secundario) lo que da como resultado que 0 sea alertado.

Pero, ¿qué es alguien que viene y mueve el espacio?

var i = 0, j = 0;
alert(i+ ++j);

Ahora, esto primero incrementa j, y luego agrega i al nuevo valor de j, lo que da como resultado que se alerte a 1.

Esto podría solucionarse fácilmente haciendo

var i = 0, j = 0;
alert((i++) +j); 

Ahora bien, esto no puede estar equivocado.

  • Gracias por la explicación. Intenté poner el (e++) en lugar de e++, pero persiste JSLint.

    – KdgDev

    8 de junio de 2010 a las 20:13

  • Ok, entonces solo necesitas configurar plusplus: false en sus opciones jslint. Eso debería deshabilitar ese cheque.

    – Sean Kinsey

    8 de junio de 2010 a las 21:07

  • jslint parece ser arbitrariamente pedante al respecto. ¿Cuántos millones de bucles for están claramente escritos con un i++? Y de alguna manera todos hemos sobrevivido a pesar de la falta de paréntesis que rodeen y protejan la declaración de incremento.

    – Queso

    23 de agosto de 2011 a las 18:48

  • @Cheeso, es una gran diferencia entre una sola expresión en forma de i++ y una AdditionExpresion compuesta donde uno de los operandos es una expresión unaria. Pero esto no tiene nada que ver con el lexer, se trata de crear código conciso donde toda la intención se comunica claramente.

    – Sean Kinsey

    24 de agosto de 2011 a las 9:05


  • @Sean Kinsey, el último ejemplo aún alertará a 0, y al leer el código todavía no está claro cuál era el propósito previsto, en realidad parece que el código incrementará la i primero, pero no lo hará.

    – Pablo Scheltema

    5 de abril de 2013 a las 11:31

avatar de usuario
samir talwar

Personalmente, prefiero poner afirmaciones como i++ en una línea por sí mismos. Incluirlos como parte de una declaración más grande puede causar confusión para aquellos que no están seguros de lo que se supone que debe hacer la línea.

Por ejemplo, en lugar de:

value = func(i++ * 3);

Yo haría esto:

value = func(i * 3);
i++;

También significa que las personas no tienen que recordar cómo i++ y ++i trabajo, y elimina la necesidad de aplicar tantas reglas de preferencia.

avatar de usuario
benzonico

El verdadero problema de la ++ operador es que es un operador con efectos secundarios y por lo tanto es totalmente opuesto al principio de programación funcional.

Los “funcional“manera de implementar i++ sería i = i + 1 donde reasignas explícitamente la variable sin efectos secundarios y luego la usas.

La posibilidad de confusión es que ++ hace dos cosas al agregar un valor Y reasignarlo a la variable.

  • incluso Lisp (así como Mathematica) tiene ambos (1+ num) y (incf 1) … porque tener ++ se trata principalmente de sintaxis (porque es esencialmente un azúcar sintáctico), no sobre la semántica de uso. hay siempre una posibilidad de confusión; algunos lenguajes (ver arriba) asumen la cordura del programador, otros (Python, R, MATLAB) no. No me corresponde a mí decidir cuáles tienen razón. Aún así, JavaScript no es más “funcional” que el actual C++, C# o Java (lambdas, cierres, etc.)

    usuario719662

    18 de julio de 2017 a las 17:48


  • Eso no es del todo cierto. i = i + 1 tiene los mismos efectos secundarios que i++ . i++ es solo una abreviatura. en i = i + 1 mutas el valor de i. por eso por ejemplo en scala solo lo puedes usar con var y no val para mostrar que muta el valor. no veo como i = i + 1 es mas funcional que i++ si ambos tienen los mismos efectos secundarios.

    – Claudiu Creanga

    30 de agosto de 2017 a las 9:18


  • @robinCTS The truth of the matter is that i = i + 1 has no side effect Tiene efectos secundarios porque mutas el valor. ¿Cómo es que no puedes usarlo como val si dices que no tiene efectos secundarios?

    – Claudiu Creanga

    4 oct 2017 a las 11:27

  • @vaxquis & ClaudiuCreanga A menos que tenga un completo malentendido de lo que realmente significa ‘lado’;)

    – robinCTS

    4 oct 2017 a las 17:58

  • @robinCTS ver softwareengineering.stackexchange.com/questions/40297/… ; lo que dices es un concepto erróneo (lamentablemente) muy común. En el contexto de FP, se usa “efecto secundario” exclusivamente para describir la mutación del estado (frente a las funciones puras, que no tienen se ni mutaciones de estado). En cuanto a su ejemplo, una vez más, lo está haciendo mal, por las razones que describí anteriormente; “no use asignaciones/++/– en expresiones complejas” es una muy pauta común, presente en prácticamente cualquier IDE decente. Simplemente enciéndalo y deje de preocuparse por los casos que nunca verá en un código cuerdo.

    usuario719662

    4 oct 2017 a las 18:06


avatar de usuario
Perspectiva Geográfica

Bucle compatible con JSLint

for (i = 0; i < 10; i += 1) {
    //Do somthing
}

  • incluso Lisp (así como Mathematica) tiene ambos (1+ num) y (incf 1) … porque tener ++ se trata principalmente de sintaxis (porque es esencialmente un azúcar sintáctico), no sobre la semántica de uso. hay siempre una posibilidad de confusión; algunos lenguajes (ver arriba) asumen la cordura del programador, otros (Python, R, MATLAB) no. No me corresponde a mí decidir cuáles tienen razón. Aún así, JavaScript no es más “funcional” que el actual C++, C# o Java (lambdas, cierres, etc.)

    usuario719662

    18 de julio de 2017 a las 17:48


  • Eso no es del todo cierto. i = i + 1 tiene los mismos efectos secundarios que i++ . i++ es solo una abreviatura. en i = i + 1 mutas el valor de i. por eso por ejemplo en scala solo lo puedes usar con var y no val para mostrar que muta el valor. no veo como i = i + 1 es mas funcional que i++ si ambos tienen los mismos efectos secundarios.

    – Claudiu Creanga

    30 de agosto de 2017 a las 9:18


  • @robinCTS The truth of the matter is that i = i + 1 has no side effect Tiene efectos secundarios porque mutas el valor. ¿Cómo es que no puedes usarlo como val si dices que no tiene efectos secundarios?

    – Claudiu Creanga

    4 oct 2017 a las 11:27

  • @vaxquis & ClaudiuCreanga A menos que tenga un completo malentendido de lo que realmente significa ‘lado’;)

    – robinCTS

    4 oct 2017 a las 17:58

  • @robinCTS ver softwareengineering.stackexchange.com/questions/40297/… ; lo que dices es un concepto erróneo (lamentablemente) muy común. En el contexto de FP, se usa “efecto secundario” exclusivamente para describir la mutación del estado (frente a las funciones puras, que no tienen se ni mutaciones de estado). En cuanto a su ejemplo, una vez más, lo está haciendo mal, por las razones que describí anteriormente; “no use asignaciones/++/– en expresiones complejas” es una muy pauta común, presente en prácticamente cualquier IDE decente. Simplemente enciéndalo y deje de preocuparse por los casos que nunca verá en un código cuerdo.

    usuario719662

    4 oct 2017 a las 18:06


avatar de usuario
mikeelprogramador

Tenga en cuenta que el operador ++ depende de la posición con respecto a la variable anterior/siguiente y la nueva línea/punto y coma para determinar el orden de las operaciones.

var a = 1;
var b = a++;
console.log(b); // b = 1
console.log(a); // a = 2

var a = 1;
var b = ++a;
console.log(b); // b = 2
console.log(a); // a = 2

¿Ha sido útil esta solución?