Assegnazione booleana delle migliori pratiche [chiuso]

Mi sono imbattuto nel seguente condizionale in un programma che ho rilevato da un altro sviluppatore:

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.NeedsChange = false;
}

Credo che questo codice sia ridondante e brutto, quindi l'ho cambiato in quello che pensavo fosse un semplice compito booleano basato su un confronto:

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE;

Vedendo ciò, qualcuno che ha esaminato il mio codice ha commentato che sebbene la mia modifica sia funzionalmente corretta, potrebbe confondere qualcun altro che lo sta guardando. Crede che l'uso di un operatore ternario renda più chiaro questo compito, mentre non mi piace l'aggiunta di un codice più ridondante:

obj.NeedsChange = (obj.Performance <= LOW_PERFORMANCE) ? true : false;

Il suo ragionamento è che fare qualcosa nel modo più conciso non ne vale la pena, se fa sì che un altro sviluppatore debba fermarsi e risolvere esattamente ciò che hai fatto.

La vera domanda qui è quale di questi tre metodi per assegnare un valore al booleano obj.NeedsChangeè il più chiaro e il più mantenibile?

Preferisco 2, ma potrei fare una piccola modifica:

obj.NeedsChange = ( obj.Performance <= LOW_PERFORMANCE );

Per me le parentesi facilitano l'analisi della linea e chiariscono a colpo d'occhio che si sta assegnando il risultato di un confronto e non si sta eseguendo una doppia assegnazione. Non sono sicuro del perché (in quanto non riesco a pensare a una lingua in cui le parentesi impedirebbero effettivamente un doppio incarico), ma se devi soddisfare il tuo recensore, forse questo sarà un compromesso accettabile.

La variante 1 è facilmente comprensibile, ma è l'unico vantaggio. Suppongo automaticamente che chiunque scriva in questo modo non capisca veramente di cosa si tratti i booleani e scriverà codice altrettanto infantile sotto molti altri aspetti.

La variante 2 è ciò che scrivo sempre e mi aspetto di leggere. Penso che chiunque sia confuso da quell'idioma non dovrebbe essere uno scrittore professionista di software.

La variante 3 combina gli svantaggi di 1 e 2. 'Nuff ha detto.

Ogni volta che il codice è più complicato di quello che deve essere innesca un "cosa dovrebbe fare questo?" odore nel lettore.

Ad esempio, il primo esempio mi fa meravigliare: "c'erano altre funzionalità nell'istruzione if / else a un certo punto che è stata rimossa?"

L'esempio (2) è semplice, chiaro e fa esattamente ciò che è necessario. L'ho letto e capisco immediatamente cosa fa il codice.

La lanugine in più in (3) mi farebbe chiedermi perché l'autore lo abbia scritto in questo modo invece di (2). Ci dovrebbe essere una ragione, ma in questo caso non sembra essere, quindi non è utile a tutti e più difficile da leggere perché suggerisce qualcosa di presente, che non c'è la sintassi. Cercare di imparare ciò che è presente (quando non c'è nulla) rende il codice più difficile da leggere.

È facile vedere che la variante 2 e la variante 1 sono correlate tramite una serie di refactoring ovvi e semplici:

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.NeedsChange = false;
}

Qui, abbiamo inutili duplicazioni di codice, possiamo scomporre l'assegnazione:

obj.NeedsChange = if (obj.Performance <= LOW_PERFORMANCE)
{
    true
}
else
{
    false
}

o scritto in modo più conciso:

obj.NeedsChange = if (obj.Performance <= LOW_PERFORMANCE) true else false

Ora, dovrebbe essere immediatamente ovvio che questo assegnerà vero se la condizione è vera e assegnerà falso se la condizione è falsa, IOW assegnerà semplicemente il valore della condizione, cioè è equivalente a

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE

Le varianti 1 e 3 sono il tipico codice da principiante scritto da qualcuno che non capisce quale sia il valore di ritorno di un confronto.

Mentre la programmazione dovrebbe tendono verso esplicito sopra implicito "come se il ragazzo che finisce per mantenere il vostro codice sarà uno psicopatico violento che sa dove si vive", si può supporre alcune cose di base che il vostro successore psico sarà competente.

Uno di questi è la sintassi della lingua che sta usando.

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE;

è molto chiaro a chiunque conosca la sintassi C / C ++ / C # / Java / Javascript.

È anche molto più leggibile di 8 righe.

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.NeedsChange = false;
}

e meno incline agli errori

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.Needschange = false;
}

Ed è meglio che aggiungere caratteri non necessari, come se avessi quasi dimenticato la sintassi della lingua:

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE ? true : false;

obj.NeedsChange = (obj.Performance <= LOW_PERFORMANCE);

Penso che ci sia molto di sbagliato nella sintassi simil-C di molte lingue: ordine delle operazioni incoerente, associatività sinistra / destra incoerente, usi sovraccarichi di simboli, duplicazione parentesi graffe / rientri, operatori ternari, notazione infissi, ecc.

Ma la soluzione non è inventare la tua versione proprietaria. In questo modo risiede la follia, poiché ognuno crea il proprio.

Generalmente la cosa numero 1 che rende illeggibile il codice Real World ^TM è la sua quantità.

Tra un programma non patologico a 200 linee e un programma banalmente identico a 1.600 linee, quello più corto sarà quasi sempre più facile da analizzare e comprendere. Gradirei il tuo cambiamento ogni giorno.

La maggior parte degli sviluppatori sarà in grado di comprendere la seconda forma con uno sguardo. A mio avviso, la semplificazione come nella prima forma è semplicemente superflua.

È possibile migliorare la leggibilità aggiungendo spazi e parentesi graffe come:

obj.NeedsChange =    obj.Performance <= LOW_PERFORMANCE;

o

obj.NeedsChange = ( obj.Performance <= LOW_PERFORMANCE );

come menzionato da Jacob Raihle.