Quando sono assegnati compiti concatenati (cioè a = b = c) in forma errata?

Non lo faccio mai. Metto sempre ogni incarico su una propria linea. La chiarezza è il re.

In pratica, utilizzo raramente variabili di stato sufficienti per rendere necessari i concatenamenti di concatenamento. Se arrivo a quel punto, inizio a cercare modi per ridurre la quantità di stato che sto usando.

Dipende dal linguaggio di programmazione. Se utilizzi una lingua in cui i tipi di variabile non vengono applicati, ciò potrebbe accadere.

x = 1;
y = 494.0;
z = new Object();
x = y = z = "hello";

Ora x, y, z sono tutti una stringa. Questo potrebbe confondere se trovato più avanti nel codice.

L'altro problema sono gli overload dell'operatore. Alcune lingue ti consentono di cambiare ciò che accade per l'assegnazione a sinistra di una proprietà. Quindi potrebbe succedere il seguente.

x = y.something = 0;

Dove y.something non restituisce 0 . Restituisce null .

Altrimenti, non ho problemi con questo. Se si tratta di una lingua strongmente tipizzata e non vi è alcun rischio nel verificarsi di quanto sopra. Quindi nessun problema.

L'altro problema riguarda il modo in cui leggi il codice sorgente.

 a = b = c = new Object();

Non è uguale a.

 a = new Object();
 b = new Object();
 c = new Object();

È davvero così.

 c = new Object();
 b = c;
 a = b;

Potrebbe non essere chiaro che tutte e tre le variabili hanno lo stesso riferimento.

Non è necessariamente un codice cattivo, ma rende il tuo codice significativamente meno leggibile. In genere, raccomanderei strongmente contro di esso, anche se suppongo che ci siano alcuni casi in cui potrebbe essere accettabile (o semplicemente meno cattivo). Ad esempio, quando si impostano alcune variabili locali su un valore costante:

// accumulators
int j = 0, k = 0;
for(int i = 0; ...)
{
    ...
    if(reset)
    {
        // oops we have to start from the beginning
        i = j = k = 0;
    }
}

In questo caso la linea, e ancora più importante il commento che la accompagna, chiarisce quale fosse l'intenzione dell'autore quando lo scriveva. Questo codice contiene anche una dichiarazione composta che anch'io generalmente scoraggio, ma qui sono più accettabili per le stesse ragioni.

Tuttavia, lo raccomanderei contro nella maggior parte dei casi. Non c'è mai alcun danno nello scrivere codice più esplicito (purché sia funzionalmente identico).