Rendere più semplici le dichiarazioni IF

6

Se supponiamo di avere questo piccolo frammento di codice:

string str = "checked";
bool test1;

if (str == "checked")
{
    test1 = true;
}
else
{
    test1 = false;
}

È una cattiva pratica cambiare una semplice affermazione come questa di seguito?:

bool test2 = (str == "checked");

Perché funzionano esattamente allo stesso modo e funzionano come richiesto, quindi non posso immaginare come sarebbe. Tuttavia, da giovane programmatore inesperto non sono a conoscenza se una cosa del genere sia disapprovata o meno. Qualcuno può dirmi, se questo NON è ok, perché no?

Il seguente programma di test:

using System;

public class Test
{

    public static void Main()
    {
        string str = "checked";

        bool test1;

        if (str == "checked")
        {
            test1 = true;
        }
        else
        {
            test1 = false;
        }

        bool test2 = (str == "checked");

        bool test3 = (str != "checked");

        Console.WriteLine(test1.ToString());
        Console.WriteLine(test2.ToString());
        Console.WriteLine(test3.ToString());
    }
}

Uscite:

True
True
False

Qualsiasi comprensione ecc. è apprezzata.

    
posta Felix Weir 30.05.2013 - 17:08
fonte

6 risposte

33

Is it bad practice to change a simple statement like this to the following?:

bool test2 = (str == "checked");

No, è una buona pratica. Per me, il codice più lungo:

if (str == "checked")
{  
    test1 = true;
}
else
{
    test1 = false;
} 

indica che il programmatore non comprende le espressioni booleane. La forma più breve è molto più chiara. Allo stesso modo, non scrivere:

if (boolean-expression) {
    return true;
} else {
    return false;
}

Scrivi return boolean-expression;

    
risposta data 30.05.2013 - 17:16
fonte
12

Sarei molto seccato con qualcuno che ha usato il modulo lungo quando la frase è così semplice.

Indica che chi lo ha scritto non capisce i tipi di dati booleani o non si rende conto che == è indipendente da if .

    
risposta data 30.05.2013 - 17:13
fonte
6

Mentre la forma più breve è più elegante e compatta, il formato lungo offre un vantaggio: puoi facilmente impostare un punto di interruzione a test1 = true , mentre non puoi con il modulo più corto.

    
risposta data 30.05.2013 - 23:55
fonte
2

Chi vedrà il tuo codice?

Se pensi che gli altri che potrebbero vedere il tuo codice verranno confusi con le dichiarazioni di una riga if , quindi utilizza la versione completa. Inoltre, se pensi che potresti invertire accidentalmente la logica, quindi spelling fuori.

Esempio:
In un precedente lavoro, ho avuto colleghi che hanno richiesto la logica completa e definita. Quando hanno provato a usare le one-liner, avrebbero riavviato la logica su base regolare. Dove sono ora, la compagnia è piena di persone intelligenti che farebbero molto raramente (se mai) quell'errore. Qui, annidiamo le dichiarazioni di% co_de ternario senza confusione.

    
risposta data 30.05.2013 - 18:16
fonte
2

Rispondendo all'ipotesi che questa affermazione booleana sia sempre così semplice, non ho dubbi sul fatto che lo slogan semplificato:

bool test2 = (str == "checked");

sarebbe sufficiente, e sicuramente produce meno linee di IL. Nel mio esperimento con Mono ho trovato la dichiarazione su una riga prodotta:

IL_0000: ldstr "test"
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: ldstr "test"
IL_000c: call bool [mscorlib]System.String::op_Equality(string, string)
IL_0011: stloc.1
IL_0012: ldloc.1

Mentre la tradizionale dichiarazione if-else ha prodotto:

IL_0000: ldstr "test2"
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: ldstr "test2"
IL_000c: call bool [mscorlib]System.String::op_Equality(string, string)
IL_0011: brfalse IL_001d

IL_0016: ldc.i4.1
IL_0017: stloc.1
IL_0018: br IL_001f

IL_001d: ldc.i4.0
IL_001e: stloc.1

IL_001f: ldloc.1
IL_0020: ret
IL_0013: ret

Sembra che nel mio caso il compilatore Mono abbia creato diverse subroutine e gestisca una serie di chiamate per gestire l'if-else.

Detto questo, se l'operazione booleana diventa più complessa, quindi, per motivi di leggibilità, in un ambiente di sviluppo professionale, lo cambierei almeno in:

if (/*complex boolean operation*/)
    // set state in case of true evaluation
else
    // set state in case of false evaluation

Senza ulteriore contesto non posso fornirti una soluzione migliore.

    
risposta data 30.05.2013 - 18:28
fonte
-4

A rischio di essere downvoted nel dimenticatoio, direi usare la forma lunga a causa della chiarezza e della manutenibilità. Nell'esempio fornito, la differenza è piccola. Ma prendere l'abitudine di scrivere one-liner "intelligenti" renderà più difficile a chiunque altro mantenere il proprio codice.

    
risposta data 31.05.2013 - 00:10
fonte