it-swarm.it

Singola istruzione se blocco - parentesi graffe o no?

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ò.

59
Zann Anderson

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 fa quello che fa realmente, rendendolo meno soggetto a errori. Purché questa sintassi venga utilizzata solo per istruzioni e condizioni molto semplici, brevi, la trovo perfettamente leggibile.

131
dsimcha

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.

44
Neil Aitken

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 regge.

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.1

È 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 tu non usi un monitor rivolto verso l'alto, 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 che tu possa vedere l'intero blocco senza scorrere.

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), consecutivo le righe vuote sono uno stile errato molto nel mio libro (e nella mia esperienza di solito sono 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 le parentesi graffe forse non fa male

C'è solo uno 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 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 ho dimenticato non una volta di aggiungere le parentesi quando si aggiunge 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 trattino la nuova dichiarazione aggiunta correttamente, dopo tutto; così il programmatore ha già elaborato mentalmente che è coinvolto un blocco.

Ora, I am not dicendo che omettere le parentesi graffe non causa errori. Quello che sto dicendo è che non abbiamo prove in un modo o nell'altro. Semplicemente non so se provoca danno.

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 messo alla prova, e questo deve essere no usato come argomento.


1 A volte questo problema 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.

27
Konrad Rudolph

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.

19
Steven Evers

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 ;-)

16
rubber boots

Uso il metodo delle parentesi graffe - per tutti i motivi di cui sopra più 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 è 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.

11
user36294

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.

10
Covar

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 blocco if, 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 anche.

8
shimonyk

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

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

7
Steven A. Lowe

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 il 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.

5
jsternberg

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 condizione if deve adattarsi perfettamente su una singola riga e l'istruzione 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'istruzione if (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 c'è così tanto annidamento 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 uso questo modulo dell'istruzione if.

    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 il debug e/o l'aggiunta di codice.

3

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 coerente il formato delle istruzioni if, indipendentemente dal numero di istruzioni presenti nel blocco.

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

2
ChrisF

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!");
1
JohnFx

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

If (cond) { statement; }
1
hotpaw2

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 un'istruzione dopo return, abbiamo problemi più grandi di quelli relativi all'ambito.

Se il IDE ha la formattazione del codice disponibile non uso 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.

0
nimcap