Perché evitare gli operatori di incremento (“++”) e decremento (“-”) in JavaScript?

Uno dei suggerimenti per lo strumento jslint è:

++ e -
È noto che gli operatori ++ (incremento) e - (decremento) contribuiscono al cattivo codice incoraggiando l'eccessiva inganno. Sono secondi solo all'architettura difettosa nel consentire a virus e altre minacce alla sicurezza. Esiste un'opzione plusplus che vieta l'uso di questi operatori.

So che PHP costruisce come $foo[$bar++]potrebbe facilmente comportare errori off-by-one, ma non sono riuscito a trovare un modo migliore per controllare il loop di un while( a < 10 ) do { /* foo */ a++; }o for (var i=0; i<10; i++) { /* foo */ }.

Il jslint li sta evidenziando perché ci sono alcuni linguaggi simili che mancano della " ++" e " --" sintassi o la gestiscono in modo diverso, o ci sono altre motivazioni per evitare " ++" e " --" che potrebbero mancare?

La mia opinione è di usare sempre ++ e - da soli su una sola riga, come in:

i++;
array[i] = foo;

invece di

array[++i] = foo;

Qualunque cosa oltre a ciò può essere fonte di confusione per alcuni programmatori e non ne vale la pena a mio avviso. I loop sono un'eccezione, poiché l'uso dell'operatore di incremento è idiomatico e quindi sempre chiaro.

Sono francamente confuso da quel consiglio. Una parte di me si chiede se abbia più a che fare con la mancanza di esperienza (percepita o effettiva) con i programmatori javascript.

Vedo come qualcuno che semplicemente "hackerando" un po 'di codice di esempio potrebbe commettere un errore innocente con ++ e -, ma non vedo perché un professionista esperto li eviti.

C'è una storia in C nel fare cose come:

while (*a++ = *b++);

per copiare una stringa, forse questa è la fonte dell'eccessivo inganno a cui si sta riferendo.

E c'è sempre la domanda su cosa

++i = i++;

o

i = i++ + ++i;

davvero. È definito in alcune lingue e in altre non c'è garanzia su cosa accadrà.

A parte questi esempi, non penso che ci sia qualcosa di più idiomatico di un ciclo for che usa ++per incrementare. In alcuni casi potresti cavartela con un ciclo foreach o un ciclo while che controllava una condizione diversa. Ma contorcendo il tuo codice per cercare di evitare l'uso dell'incremento è ridicolo.

Se leggi JavaScript The Good Parts, vedrai che la sostituzione di Crockford per i ++ in un ciclo for è i + = 1 (non i = i + 1). È abbastanza pulito e leggibile, ed è meno probabile che si trasformi in qualcosa di "difficile".

Crockford ha fatto del divieto di autoincrement e autodecrement un'opzione in jsLint. Scegli se seguire i consigli o meno.

La mia regola personale è di non fare nulla in combinazione con l'autoincremento o l'auto-miglioramento.

Ho imparato da anni di esperienza in C che non ottengo sovraccarichi del buffer (o indice di array fuori limite) se continuo a usarlo in modo semplice. Ma ho scoperto che ottengo sovraccarichi del buffer se cado nella pratica "eccessivamente complicata" di fare altre cose nella stessa affermazione.

Quindi, per le mie regole, l'uso di i ++ come incremento in un ciclo for va bene.

In un ciclo è innocuo, ma in un'istruzione di assegnazione può portare a risultati imprevisti:

var x = 5;
var y = x++; // y is now 5 and x is 6
var z = ++x; // z is now 7 and x is 7

Lo spazio bianco tra la variabile e l'operatore può portare anche a risultati imprevisti:

a = b = c = 1; a ++ ; b -- ; c; console.log('a:', a, 'b:', b, 'c:', c)

In una chiusura, anche i risultati imprevisti possono essere un problema:

var foobar = function(i){var count = count || i; return function(){return count++;}}

baz = foobar(1);
baz(); //1
baz(); //2


var alphabeta = function(i){var count = count || i; return function(){return ++count;}}

omega = alphabeta(1);
omega(); //2
omega(); //3

E innesca l'inserimento automatico di punti e virgola dopo una nuova riga:

var foo = 1, bar = 2, baz = 3, alpha = 4, beta = 5, delta = alpha
++beta; //delta is 4, alpha is 4, beta is 6

la confusione preincremento / postincremento può produrre errori singoli che sono estremamente difficili da diagnosticare. Fortunatamente, sono anche inutili. Esistono modi migliori per aggiungere 1 a una variabile.

Riferimenti

• JSLint Help: Operatori di incremento e decremento

Considera il seguente codice

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[i++] = i++;
    a[i++] = i++;
    a[i++] = i++;

poiché i ++ viene valutato due volte l'output è (dal debugger vs2005)

    [0] 0   int
    [1] 0   int
    [2] 2   int
    [3] 0   int
    [4] 4   int

Ora considera il seguente codice:

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[++i] = ++i;
    a[++i] = ++i;
    a[++i] = ++i;

Si noti che l'output è lo stesso. Ora potresti pensare che ++ ie i ++ siano uguali. Non sono

    [0] 0   int
    [1] 0   int
    [2] 2   int
    [3] 0   int
    [4] 4   int

Infine considera questo codice

    int a[10];
    a[0] = 0;
    a[1] = 0;
    a[2] = 0;
    a[3] = 0;
    int i = 0;
    a[++i] = i++;
    a[++i] = i++;
    a[++i] = i++;

L'output è ora:

    [0] 0   int
    [1] 1   int
    [2] 0   int
    [3] 3   int
    [4] 0   int
    [5] 5   int

Quindi non sono gli stessi, mescolando entrambi si ottiene un comportamento non così intuitivo. Penso che per i loop vada bene con ++, ma fai attenzione quando hai più simboli ++ sulla stessa riga o sulla stessa istruzione

La natura "pre" e "post" degli operatori di incremento e decremento può tendere a confondere chi non li conosce; questo è un modo in cui possono essere difficili.

A mio avviso, "L'esplicito è sempre meglio che implicito". Perché ad un certo punto, potresti essere confuso con questa dichiarazione di incrementi y+ = x++ + ++y. Un buon programmatore rende sempre più leggibile il proprio codice.

La logica più importante per evitare ++ o - è che gli operatori restituiscano valori e causino effetti collaterali allo stesso tempo, rendendo più difficile ragionare sul codice.

Per motivi di efficienza, preferisco:

• ++ i quando non si utilizza il valore restituito (nessun temporaneo)
• i ++ quando si utilizza il valore restituito (nessuna stallo della pipeline)

Sono un fan del signor Crockford, ma in questo caso non sono d'accordo. ++iè il 25% in meno di testo da analizzare di i+=1 e probabilmente più chiaro.

Ho visto il video di Douglas Crockford su questo e la sua spiegazione per non usare l'incremento e il decremento è quella

1. È stato usato in passato in altre lingue per rompere i limiti degli array e causare tutti i modi di cattiveria e
2. Che gli sviluppatori JS siano più confusi e inesperti non sanno esattamente cosa faccia.

Innanzitutto gli array in JavaScript hanno dimensioni dinamiche e quindi, perdonami se sbaglio, non è possibile rompere i limiti di un array e accedere ai dati a cui non si dovrebbe accedere utilizzando questo metodo in JavaScript.

In secondo luogo, dovremmo evitare cose che sono complicate, sicuramente il problema non è che abbiamo questa funzione ma il problema è che ci sono sviluppatori là fuori che affermano di fare JavaScript ma non sanno come funzionano questi operatori ?? È abbastanza semplice. value ++, dammi il valore corrente e dopo l'espressione aggiungine uno, ++ value, incrementa il valore prima di darmelo.

Espressioni come a ++ + ++ b, sono semplici da capire se ricordi solo quanto sopra.

var a = 1, b = 1, c;
c = a ++ + ++ b;
// c = 1 + 2 = 3; 
// a = 2 (equals two after the expression is finished);
// b = 2;

Suppongo che devi solo ricordare chi deve leggere il codice, se hai una squadra che conosce JS a fondo, allora non devi preoccuparti. In caso contrario, commentalo, scrivilo in modo diverso, ecc. Fai quello che devi fare. Non credo che l'incremento e il decremento siano intrinsecamente cattivi o che generano bug o creano vulnerabilità, forse solo meno leggibili a seconda del pubblico.

A proposito, penso che Douglas Crockford sia comunque una leggenda, ma penso che abbia causato molta paura su un operatore che non se lo meritava.

Vivo per essere smentito però ...

Un altro esempio, più semplice di alcuni altri con un semplice ritorno di valore incrementato:

function testIncrement1(x) {
    return x++;
}

function testIncrement2(x) {
    return ++x;
}

function testIncrement3(x) {
    return x += 1;
}

console.log(testIncrement1(0)); // 0
console.log(testIncrement2(0)); // 1
console.log(testIncrement3(0)); // 1

Come puoi vedere, nessun post-incremento / decremento dovrebbe essere usato nell'istruzione return, se vuoi che questo operatore influenzi il risultato. Ma return non "cattura" gli operatori post-incremento / decremento:

function closureIncrementTest() {
    var x = 0;

    function postIncrementX() {
        return x++;
    }

    var y = postIncrementX();

    console.log(x); // 1
}

Penso che i programmatori dovrebbero essere competenti nella lingua che stanno usando; usalo chiaramente; e usalo bene. Io non credo che dovrebbero artificialmente paralizzare la lingua che stanno utilizzando. Parlo per esperienza. Una volta ho lavorato letteralmente accanto a un negozio Cobol dove non usavano ELSE "perché era troppo complicato". Reductio ad absurdam.

Come menzionato in alcune delle risposte esistenti (di cui non sono fastidioso commentare), il problema è che x ++ ++ x valuta valori diversi (prima rispetto a dopo l'incremento), il che non è ovvio e può essere molto confuso - se viene utilizzato quel valore. cdmckay suggerisce abbastanza saggiamente di consentire l'uso dell'operatore di incremento, ma solo in modo tale da non utilizzare il valore restituito, ad esempio sulla propria riga. Includerei anche l'uso standard all'interno di un ciclo for (ma solo nella terza istruzione, il cui valore di ritorno non viene utilizzato). Non riesco a pensare a un altro esempio. Essendo stato "bruciato" da solo, consiglierei la stessa linea guida anche per altre lingue.

Non sono d'accordo con l'affermazione che questa rigidità eccessiva è dovuta alla mancanza di esperienza di molti programmatori JS. Questo è il tipo esatto di scrittura tipico dei programmatori "troppo intelligenti", e sono sicuro che sia molto più comune nei linguaggi più tradizionali e con gli sviluppatori JS che hanno un background in tali linguaggi.

Nella mia esperienza, ++ i o i ++ non hanno mai causato confusione se non quando si è appreso per la prima volta come funziona l'operatore. È essenziale per i più elementari per i cicli e mentre i cicli sono tenuti da qualsiasi corso di scuola superiore o college tenuto in lingue in cui è possibile utilizzare l'operatore. Personalmente trovo che fare qualcosa di simile a ciò che è sotto per guardare e leggere meglio di qualcosa con un ++ sia su una linea separata.

while ( a < 10 ){
    array[a++] = val
}

Alla fine è una preferenza di stile e non di più, ciò che è più importante è che quando lo fai nel tuo codice rimani coerente in modo che altri che lavorano sullo stesso codice possano seguire e non debbano elaborare la stessa funzionalità in modi diversi .

Inoltre, Crockford sembra usare i- = 1, che trovo più difficile da leggere di --i o i--

Il mio 2 centesimi è che dovrebbero essere evitati in due casi:

1) Quando si dispone di una variabile che viene utilizzata in più righe e la si aumenta / diminuisce sulla prima istruzione che la utilizza (o l'ultima, o, peggio ancora, nel mezzo):

// It's Java, but applies to Js too
vi = list.get ( ++i );
vi1 = list.get ( i + 1 )
out.println ( "Processing values: " + vi + ", " + vi1 )
if ( i < list.size () - 1 ) ...

In esempi come questo, puoi facilmente perdere il fatto che la variabile viene auto-incrementata / decrementata o addirittura rimuovere la prima istruzione. In altre parole, usalo solo in blocchi molto brevi o in cui la variabile appare nel blocco solo su un paio di istruzioni vicine.

2) Nel caso di più ++ e - circa la stessa variabile nella stessa istruzione. È molto difficile ricordare cosa succede in casi come questo:

result = ( ++x - --x ) * x++;

Esami e test professionali fanno domande su esempi come sopra e in effetti mi sono imbattuto in questa domanda mentre cercavo la documentazione su uno di essi, ma nella vita reale non si dovrebbe essere costretti a pensare così tanto a una singola riga di codice.

Fortran è un linguaggio simile al C? Non ha né ++ né -. Ecco come si scrive un ciclo :

     integer i, n, sum

      sum = 0
      do 10 i = 1, n
         sum = sum + i
         write(*,*) 'i =', i
         write(*,*) 'sum =', sum
  10  continue

L'elemento index i viene incrementato dalle regole della lingua ogni volta attraverso il ciclo. Se si desidera incrementare di qualcosa di diverso da 1, contare all'indietro per due ad esempio, la sintassi è ...

      integer i

      do 20 i = 10, 1, -2
         write(*,*) 'i =', i
  20  continue

Python è C-like? Utilizza la comprensione di intervalli ed elenchi e altre sintassi per aggirare la necessità di incrementare un indice:

print range(10,1,-2) # prints [10,8.6.4.2]
[x*x for x in range(1,10)] # returns [1,4,9,16 ... ]

Quindi, sulla base di questa rudimentale esplorazione di esattamente due alternative, i progettisti del linguaggio possono evitare ++ e - anticipando i casi d'uso e fornendo una sintassi alternativa.

Fortran e Python sono in particolare meno una calamita dei bug rispetto ai linguaggi procedurali che hanno ++ e -? Non ho prove.

Sostengo che Fortran e Python sono simili a C perché non ho mai incontrato qualcuno che parla fluentemente in C che non è riuscito con una precisione del 90% a indovinare correttamente l'intento di Fortran o Python non offuscato.