Singola istruzione se blocco - parentesi graffe o no? [chiuso]

Qual è il migliore / più generalmente accettato?

Questo:

if(condition)
{
  statement;
}

O:

if(condition)
  statement;

Tendo a preferire il primo, perché penso che renda più facile dire che cosa effettivamente appartiene al blocco if, salva gli altri dall'aggiunta delle parentesi graffe in seguito (o dalla creazione di un bug dimenticando di) e rende tutte le tue istruzioni if uniforme invece di alcuni con bretelle e alcuni senza. Il secondo, tuttavia, è ancora sintatticamente corretto e decisamente più compatto. Sono curioso di vedere quale è generalmente più preferito dagli altri però.

Il primo è migliore perché il secondo è soggetto a errori. Ad esempio, supponiamo che tu stia commentando temporaneamente il codice per eseguire il debug di qualcosa:

if(condition) 
//      statement;
otherStatement;

O aggiungendo il codice in fretta:

if(condition) 
    statement;
    otherStatement;

Questo è ovviamente negativo. D'altra parte, il primo a volte sembra troppo prolisso. Pertanto, preferisco mettere tutto su una riga se è sufficientemente breve e semplice:

if(condition) statement;

Ciò riduce il rumore sintattico mentre fa sembrare il costrutto come se facesse quello che fa effettivamente, rendendolo meno soggetto a errori. Purché questa sintassi sia utilizzata solo per istruzioni e condizioni molto semplici, brevi, la trovo perfettamente leggibile.

Uso sempre le parentesi solo per sicurezza.

Va bene quando lo scrivi, ma sai che qualcuno arriverà in futuro e inserirà un'altra dichiarazione senza mettere parentesi.

Preferisco la versione senza parentesi graffe ove possibile.

La seguente spiegazione è lunga. Per favore abbi pazienza. Darò un motivo convincente per preferire questo stile. Spiegherò anche perché penso che la solita controproposta non valga.

Le linee (quasi) vuote sono uno spreco

La ragione di ciò è che la parentesi graffa di chiusura richiede una riga di codice aggiuntiva - e anche la parentesi graffa di apertura, a seconda dello stile. ¹

È un grosso problema? Superficialmente, no. Dopotutto, molte persone inseriscono anche righe vuote nel loro codice per separare blocchi leggermente logicamente indipendenti, il che migliora notevolmente la leggibilità.

Tuttavia, detesto sprecare spazio verticale. I monitor moderni hanno in realtà un ampio spazio orizzontale. Ma lo spazio verticale è ancora molto, molto limitato (a meno che non si usi un monitor in posizione verticale, il che non è così raro). Questo spazio verticale limitato è un problema: è ampiamente riconosciuto che i singoli metodi dovrebbero essere il più corti possibile e che le parentesi graffe corrispondenti (o altri delimitatori di blocchi) non dovrebbero essere più di un'altezza dello schermo in differenza in modo da poter vedere l'intero blocco senza scrolling.

Questo è un problema fondamentale : una volta che non riesci più a vedere l'intero blocco sullo schermo, diventa complicato da capire.

Di conseguenza, detesto le righe vuote ridondanti. Dove singole righe vuote sono cruciali per delimitare blocchi indipendenti (basta guardare l'aspetto visivo di questo testo), consecutivi righe vuote sono una molto cattivo stile nel mio libro (e nella mia esperienza sono di solito un segno di programmatori alle prime armi).

Allo stesso modo, dovrebbero essere le linee che semplicemente trattengono un tutore e che potrebbero essere economizzate. Un blocco a istruzione singola che è delimitato da parentesi graffe fa perdere una o due righe. Con solo 50 linee per altezza dello schermo, questo è evidente.

Omettere parentesi graffe forse non fa male

C'è solo un argomento contro l'omissione di parentesi graffe: che qualcuno aggiungerà successivamente un'altra istruzione al blocco in questione e dimenticherà di aggiungere le parentesi graffe, cambiando così inavvertitamente la semantica del codice.

Questo sarebbe davvero un grosso problema.

Ma nella mia esperienza, non lo è. Sono un programmatore sciatto; eppure, nel mio decennio di esperienza di programmazione, posso onestamente dire che non ho mai dimenticato di aggiungere le parentesi quando ho aggiunto un'istruzione in più a un blocco singleton.

Trovo persino plausibile che si tratti di un errore comune: i blocchi sono una parte fondamentale della programmazione. La risoluzione a livello di blocco e l'ambito sono un processo mentale automatico e radicato per i programmatori. Il cervello lo fa (altrimenti, ragionare sulla programmazione sarebbe molto più difficile). Non è necessario un ulteriore sforzo mentale per ricordare di mettere le parentesi graffe: il programmatore ricorda anche di indentare correttamente la nuova dichiarazione aggiunta, dopo tutto; così il programmatore ha già elaborato mentalmente che è coinvolto un blocco.

Ora, io non dicendo che omettendo le parentesi non causa errori. Quello che sto dicendo è che non abbiamo prove in un modo o nell'altro. Semplicemente non sappiamo se provoca danni.

Quindi, finché qualcuno non può mostrarmi dati concreti, raccolti da esperimenti scientifici, che dimostrano che questo è davvero un problema nella pratica, questa teoria rimane una " storia così giusta ": un'ipotesi molto convincente che non è mai stata messa alla prova, e che non deve essere usato come argomento.

¹ Questo problema a volte viene risolto mettendo tutto - comprese le parentesi graffe - sulla stessa linea:

if (condition)
{ do_something(); }

Tuttavia, credo sia sicuro affermare che la maggior parte delle persone lo disprezza. Inoltre, avrebbe gli stessi problemi della variante senza parentesi graffe, quindi è il peggiore di entrambi i mondi.

Vado con il secondo. È più conciso e meno prolisso.

Cerco di non scrivere con il minimo comune denominatore, quindi mi aspetto che altri sviluppatori sappiano come scrivere una delle strutture di flusso di controllo più comuni nella programmazione odierna.

Vorrei usare il seguente (il consenso qui):

if (condition) {
    any_number_of_statements;
}

Inoltre possibile:

if(condition) single_compact_statement;

Non così buono, specialmente nei linguaggi simili a C / C ++:

if(condition) 
    single_compact_statement;

(Nessuna scelta qui in Python ;-)

In Perl , useresti:

$C = $A**3 if $A != $B;

o

$C = $A**3 unless $A == $B;

(Questo non è pseudocodice ;-)

Uso il metodo delle parentesi graffe - per tutti i motivi sopra e uno in più.

Il codice si fonde. È noto che accada su progetti a cui ho lavorato su quell'istruzione singola se sono stati interrotti da fusioni automatiche. La cosa spaventosa è che il rientro sembra giusto anche se il codice è sbagliato, quindi questo tipo di bug è difficile da individuare.

Quindi vado con le parentesi graffe - sulla loro linea. È più facile individuare i livelli in questo modo. Sì, spreca immobili sullo schermo verticale e questo è un vero inconveniente. A conti fatti però, penso che ne valga la pena.

Senza parentesi graffe Se qualche altro programmatore aggiunge una seconda affermazione al mio codice, non è più colpa mia se lasciare che qualcuno guidi la mia auto e vadano oltre una scogliera.

Abbiamo discusso questo argomento più di una volta qui e il consenso generale è di usare sempre le parentesi graffe. Le ragioni principali riguardano la leggibilità / manutenibilità.

Se è necessario aggiungere codice al ifblocco, non è necessario ricordare / cercare parentesi graffe. Quando i futuri programmatori leggono il codice, le parentesi graffe sono sempre inequivocabili.

Tra i lati positivi , ReSharper aggiungerà automaticamente le parentesi graffe per programmatori pigri in Visual Studio e suppongo che ci siano componenti aggiuntivi per altri IDE che lo faranno.

Uso la prima sintassi, quasi senza eccezioni. Perché non può essere frainteso .

"Non farmi pensare" non si applica solo alle interfacce utente, tutti voi ;-)

Personalmente preferisco il secondo. Il primo sembra brutto, imbarazzante e spreca spazio orizzontale. I problemi principali con il secondo sono le macro e le persone che modificano il codice in un secondo momento sbagliano.

Per questo, dico "non usare le macro". Dico anche "indenta correttamente il tuo dannato codice". Considerando come ogni editor di testo / IDE utilizzato per la programmazione fa automaticamente il rientro, questo non dovrebbe essere così difficile da fare. Quando scrivo il codice in Emacs, vorrei usare il rientro automatico per identificare se ho scritto qualcosa di sbagliato in una riga precedente. Ogni volta che Emacs inizia a rovinare il rientro, di solito so di aver fatto qualcosa di sbagliato.

In pratica, finisco per seguire qualunque convenzione di programmazione sia stata fissata prima di me. Ma questi mi infastidiscono (e mi rendono molto più felice quando scrivo codice in Python e l'intero disastro della parentesi è sparito):

if (condition) {
    statement;
} // stupid extra brace looks ugly

Poi

if (condition) // the brackets have now just become noise
{ statement; } // also can't see the indentation, harder to read

Sebbene onestamente, due affermazioni in un'istruzione if mi infastidiscono molto più di una singola affermazione. Soprattutto perché sono necessarie le parentesi quadre e sembra ancora divertente con solo due istruzioni nell'istruzione if.

Uso la versione a due righe senza parentesi graffe (la seconda forma), ma non per risparmiare spazio.

Uso questo modulo perché lo trovo più leggibile, visivamente più accattivante e più facile da scrivere. Uso questo modulo solo se tali condizioni sono soddisfatte; vale a dire che la ifcondizione deve adattarsi perfettamente su una singola riga e l'affermazione corrispondente deve adattarsi perfettamente alla riga seguente. In caso contrario, userò le parentesi graffe per migliorare la leggibilità.

Se utilizzo questo modulo, mi assicuro che sia presente una riga vuota (o una riga contenente solo una parentesi graffa) prima e dopo l' ifistruzione (o sopra il commento, se presente). Sebbene questa non sia una regola che seguo consapevolmente, ora la noto dopo aver letto questa domanda.

Conservare lo schermo non è una priorità per me. Se avessi bisogno di più spazio, utilizzerei un monitor più grande. Il mio schermo è già abbastanza grande da consentirmi di leggere qualsiasi cosa su cui potrei aver bisogno per focalizzare la mia attenzione. È improbabile che avrei bisogno di concentrarmi su così tante righe di codice contemporaneamente che occupano tutto il mio schermo. Se ci sono così tanti annidamenti in corso con un pezzo di codice che non riesco a capirlo senza visualizzarne più contemporaneamente, allora dovrei considerare se la logica potrebbe essere meglio rappresentata dal refactoring.

Di seguito sono riportati alcuni esempi che dimostrano come utilizzo questo modulo di ifdichiarazione.

    string GuardConditions(Plan planForWorldDomination)
    {
        if (planForWorldDomination == null)
            throw new ArgumentNullException("planForWorldDomination");

        if (!planForWorldDomination.IsComplete())
            return "Doh!";

        planForWorldDomination.Execute();
    }

    void ProcessingLogic()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
        OneBlankLineAbove();

        // optional comment on the line above an if statement
        if (simpleCondition)
            simpleStatement();

        OneBlankLineBelow();
    }

    void Assignment(string drive)
    {
        OneBlankLineAbove();

        string prompt;
        if (simpleCondition)
            prompt = "simple assignment";
        else
            prompt = null;

        OneBlankLineBelow();
    }

    string Return()
    {
        OneBlankLineAbove();

        if (simpleCondition)
            return "simple return";
        else
            return null;

        OneBlankLineBelow();
    }

Bretelle. Sempre. Sono una specie di fan, perché dà al codice una certa coerenza. E anche come ha scritto @dsimcha - meno possibilità di errori nell'aggiunta di ulteriori righe di codice.

La "bruttezza" delle parentesi graffe attorno a una singola riga di codice è meno dannosa del lavoro aggiuntivo che è probabile in quei casi con debug e / o aggiunta di codice.

Personalmente vado con parentesi.

Perché?

Bene, se qualcuno arriva e ha bisogno di aggiungere codice nell'istruzione if è chiaro al 100% dove si trova l'ambito.

Mantiene ifcoerente il formato delle istruzioni, indipendentemente dal numero di istruzioni presenti nel blocco.

Tuttavia, se lo stile del progetto deve andare senza, attenersi a quello.

Uso quasi sempre le parentesi solo per essere al sicuro. Tuttavia, a volte se il contenuto del blocco è davvero breve, lo lascerò fuori e lo trasformerò in un one-liner in questo modo:

if (x==5) Console.WriteLine("It's a five!");

Preferisco le parentesi graffe per coerenza, ma non sprecare troppo spazio bianco (quindi un codice formattato in modo più leggibile è nel mio campo visivo limitato). Quindi scrivo questo per righe abbastanza brevi:

If (cond) { statement; }

Di solito uso le parentesi graffe, ma ci sono alcuni casi in cui non lo faccio.

object GetObject() {
    // calculate obj1
    if(obj1 != null)
        return obj1;

    // calculate obj2
    if(obj2 != null)
        return obj2;

    // calculate obj3
    if(obj3 != null)
        return obj3;

    return defaultObj;
}

Per me, sarebbe sciocco aggiungerli lì. Se qualcuno aggiunge una dichiarazione dopo il return, abbiamo problemi più grandi rispetto ai problemi di scoping.

Se l'IDE ha la formattazione del codice disponibile, non uso le parentesi graffe.

D'altra parte, dove il codice può essere modificato in altri editor che non supportano la formattazione automatica, è pericoloso non inserire parentesi graffe come indicato in altri post. Ma anche così preferisco non usare le parentesi graffe e non è stato un problema per me.