Formattazione delle istruzioni if

Question

Questa non è una guerra santa, non è una questione di "che è meglio".

Quali sono i vantaggi dell'utilizzo del seguente formato per la singola istruzione se blocchi.

if (x) print "x is true";

if(x) 
    print "x is true";

Al contrario di

if (x) { print "x is true"; }
if(x) {
    print "x is true";    
}

Se formatti la tua singola istruzione if senza parentesi o conosci un programmatore che lo fa, cosa ti ha portato ad adottare questo stile in primo luogo?Sono particolarmente interessato a quali vantaggi ti ha portato.

Aggiornamento:Poiché la risposta più popolare ignora la domanda vera e propria (anche se presenta il consiglio più sensato), ecco una carrellata dei professionisti senza parentesi.

1. Compattezza
2. Più leggibile per alcuni
3. Le parentesi invocano l'ambito, che in alcuni casi ha un sovraccarico teorico

Answer 1

Trovo questo:

if( true ) {
    DoSomething();
} else {
    DoSomethingElse();
}

meglio di questo:

if( true )
    DoSomething();
else
    DoSomethingElse();

In questo modo, se io (o qualcun altro) tornassi a questo codice in seguito per aggiungere altro codice a uno dei rami, non dovrò preoccuparmi di dimenticare di racchiudere il codice tra parentesi graffe.I nostri occhi vedranno visivamente il rientro come indizi di ciò che stiamo cercando di fare, ma la maggior parte delle lingue no.

Answer 2

Detesto fortemente qualsiasi stile che ponga il test del se e il corpo sulla stessa linea.

Questo perché la condivisione della riga rende impossibile impostare un punto di interruzione sul corpo dell'if in molti debugger poiché i punti di interruzione sono in genere basati sul numero di riga.

Answer 3

L'utilizzo sempre delle parentesi graffe è una buona idea, ma la risposta standard che viene sempre data "Cosa succede se qualcuno aggiunge una riga di codice e si dimentica di aggiungere le parentesi graffe?" è una ragione piuttosto debole.

C'è un sottile bug che può essere introdotto non avendo le parentesi graffe dall'inizio.A me è successo alcune volte e l'ho visto succedere ad altri programmatori.

Inizia, abbastanza innocentemente, con una semplice istruzione if.

if (condition)
    do_something();
else
    do_something_else();

Il che è tutto molto bello.

Poi arriva qualcuno e aggiunge un'altra condizione all'if.Non possono aggiungerlo utilizzando && all'istruzione if stessa perché la logica sarebbe errata, quindi ne aggiungono un altro if.Ora abbiamo:

if (condition)
    if (condition2)
        do_something();
else
    do_something_else();

capisci il problema?Potrebbe sembrare giusto ma il compilatore la vede diversamente.Lo vede così:

if (condition)
    if (condition2)
        do_something();
    else
        do_something_else();

Il che significa qualcosa di completamente diverso.Il compilatore non si preoccupa della formattazione.L'altro va con l'if più vicino.Gli esseri umani, d'altra parte, fanno affidamento sulla formattazione e possono facilmente non cogliere il problema.

Answer 4

Lo uso sempre

if(x) 
{
    print "x is true";    
}

tralasciare le parentesi graffe può far sì che qualcuno che mantiene il codice pensi erroneamente di aggiungere alla clausola if se aggiunge una riga dopo la riga corrente.

Answer 5

Io uso

if (x)
{
    DoSomething();
}

per più righe, ma preferisco una riga senza parentesi:

if (x)
   DoSomething();
else
   DoSomethingElse();

Trovo le staffe estranee visivamente offensive e non ho mai fatto uno degli errori sopra menzionati che non aggiungono staffe quando aggiungo un'altra dichiarazione.

Answer 6

if
{
// code
}
else 
{
// else code
}

perché mi piace quando i blocchi di codice si allineano (comprese le parentesi graffe).

Answer 7

Se codifico:

if(x) 
    print "x is true";

e 6 mesi dopo devo aggiungere una nuova riga, la presenza di parentesi graffe rende molto meno probabile che digiterò

if(x) 
    print "x is true";
    print "x is still true";

che comporterebbe un errore logico, rispetto a:

if(x) { 
    print "x is true";
    print "x is still true";
}

Trovo quindi che le parentesi graffe rendano questi errori logici più facili da leggere ed evitare.

Answer 8

Come Matt (3 sopra), preferisco:

if (x)
{
    ...statement1
    ...statement2
}

E

if (x)
    ...statement
else
    ...statement

Penso che sia piuttosto strano pensare che qualcuno possa arrivare più tardi e NON rendersi conto di dover aggiungere le parentesi graffe per formare un blocco if su più righe.Se questo va oltre le loro capacità, mi chiedo quali siano le altre cose!

Answer 9

Singola istruzione se i blocchi sono privi di parentesi graffe:

Professionisti:

• meno caratteri
• aspetto più pulito

Contro:

• uniformità:non tutti se i blocchi sembrano uguali
• potenziale per bug quando si aggiungono istruzioni al blocco:un utente potrebbe dimenticare di aggiungere le parentesi graffe e la nuova istruzione non sarebbe coperta dall'if.

Come in:

if(x) 
    print "x is true";
    print "something else";

Answer 10

Tendo a utilizzare solo una riga singola quando provo le condizioni di interruzione all'inizio di una funzione, perché mi piace mantenere questo codice il più semplice e ordinato possibile

public void MyFunction(object param)
{
     if (param == null) return;

     ...
}

Inoltre, se trovo che voglio evitare le parentesi graffe e incorporare il codice di una clausola if, posso rigarle singolarmente, così è ovvio per chiunque aggiunga nuove righe al if che è necessario aggiungere parentesi

Answer 11

Io uso

if (cond) {
  ...
} else {
  ...
}

• Tutto dovrebbe sempre avere le parentesi graffe.Anche se ora ho solo una riga nel blocco if, ne ho aggiunte altre in seguito.
• Non metto le parentesi graffe sulle proprie linee perché è inutile spreco di spazio.
• Raramente metto il blocco sulla stessa riga del condizionale per la leggibilità.

Answer 12

Joel Spolsky ha scritto un bell'articolo: Far sembrare sbagliato il codice sbagliato

Affronta specificatamente questo tema...

if (i != 0)  
    foo(i);

In questo caso il codice è corretto al 100%;Si conforma alla maggior parte delle convenzioni di codifica e non c'è nulla di sbagliato in esso, ma il fatto che il corpo a una tenuta a singolo tetto dell'Ifstatement non sia racchiuso in parentesi graffe potrebbe essere infastidito, perché potresti pensare nella parte posteriore della tua testa, Accidenti, qualcuno potrebbe inserire un'altra riga di codice lì

if (i != 0)
    bar(i);
    foo(i);

... e dimentica di aggiungere le parentesi graffe e quindi accidentalmente di fare foo (i) incondizionato!Quindi, quando vedi blocchi di codice che non sono in parentesi graffe, potresti percepire solo una minuscola, piccola, zuppa di impurità che ti rende a disagio.

Ti suggerisce di...

... Architetto deliberatamente il tuo codice in modo tale che il naso per impurità rende il tuo codice più probabile che sia corretto.

Answer 13

Non mi piace usare l'apparecchio quando non è necessario.Mi sembra che aumenti il ​​numero di righe in un metodo e lo renda illeggibile.Quindi scelgo quasi sempre quanto segue:

if (x)
   print "x is true"
for (int i=0; i<10; i++)
   print "y is true"

E così via.Se qualcuno ha bisogno di aggiungere un'altra istruzione può semplicemente aggiungere le parentesi graffe.Anche se non hai R# o qualcosa di simile, è un affare molto piccolo.

Tuttavia, ci sono alcuni casi in cui utilizzerei le parentesi graffe anche se c'è solo una riga nell'istruzione, e cioè se la riga è particolarmente lunga o se ho bisogno di commenti all'interno di quel "se".Fondamentalmente, utilizzo semplicemente ciò che ai miei occhi sembra più bello da guardare.

Answer 14

Lo spazio bianco è tuo amico....

ma, ripeto, mi piace:

if (foo)
{
    Console.WriteLine("Foobar");
}

Answer 15

Seriamente, quando è stata l'ultima volta che hai avuto un bug in qualsiasi codice ovunque perché qualcuno ha fatto:

if (a)
  foo();
  bar();

Sì, mai...* L'unico vero "pro" qui è semplicemente abbinare lo stile del codice circostante e lasciare le battaglie estetiche ai ragazzi appena usciti dal college.

*(l'avvertenza è quando foo();sbarra();era un'espansione macro, ma questo è un problema con le macro, non con le parentesi graffe con i se.)

Answer 16

if (x) {
    print "x is true";    
}
else {
    do something else;
}

Scrivo sempre le parentesi graffe.È solo una buona abitudine.Rispetto al pensiero, scrivere non è un "lavoro".

Nota lo spazio prima del condizionale.Ciò aiuta a non sembrare una chiamata di metodo.

Answer 17

Un altro modo sarebbe scrivere:

(a==b) ? printf("yup true") : printf("nop false");

Questo sarà pratico se desideri memorizzare un valore confrontando una condizione semplice, in questo modo:

int x = (a==b) ? printf("yup true") : printf("nop false");

Answer 18

if (x)
{
    print "x is true";
}

L'apertura e la chiusura delle parentesi graffe nella stessa colonna facilita l'individuazione delle parentesi graffe non corrispondenti e isola visivamente il blocco.L'apertura della parentesi graffa nella stessa colonna di "if" rende facile vedere che il blocco fa parte di un condizionale.Lo spazio bianco extra attorno al blocco creato dalle righe contenenti solo parentesi graffe rende facile individuarne la struttura logica durante la lettura veloce del codice.Usare sempre esplicitamente le parentesi graffe aiuta a evitare problemi quando le persone modificano il codice in seguito e leggono male quali istruzioni fanno parte del condizionale e quali no: il rientro potrebbe non corrispondere alla realtà, ma essere racchiuso tra parentesi graffe lo farà sempre.

Answer 19

L'unico caso in cui l'assenza di rinforzo sembra essere accettato è quando i parametri controllano le variabili all'inizio di un metodo:

public int IndexOf(string haystack, string needle)
{
    // check parameters.
    if (haystack == null)
        throw new ArgumentNullException("haystack");
    if (string.IsNullOrEmpty(needle))
        return -1;

    // rest of method here ...

L'unico vantaggio è la compattezza.Il programmatore non deve dilungarsi tra {} non necessari quando è abbastanza ovvio che:

• il metodo esce su qualsiasi ramo vero
• è abbastanza ovvio che queste sono tutte battute di 1 linea

Detto questo, preferirei sempre {} per la logica del programma per i motivi indicati da altri.Quando si lasciano cadere le parentesi graffe è troppo facile prepararsi mentalmente quando non è presente e introdurre sottili difetti nel codice.

Answer 20

Che gli H8 siano dannati, non sono proprio uno per le regole dogmatiche.In alcune situazioni, preferirò la compattezza se non supera una certa larghezza, ad esempio:

if(x > y)      { xIsGreaterThanY(); }
else if(y > x) { yIsGreaterThanX; }
else           { xEqualsY(); }

Questo è molto più leggibile per me di:

if( x > y ){
    xIsGreaterThanY(); 
}else if( x < y){
    yIsGreaterThanX();
}else{
    xEqualsY();
}

Ciò ha l'ulteriore vantaggio di incoraggiare le persone ad astrarre la logica in metodi (come ho fatto io) piuttosto che continuare ad accumulare più logica in blocchi nidificati if-else.Inoltre occupa tre righe anziché sette, il che potrebbe consentire di non dover scorrere per visualizzare più metodi o altro codice.

Answer 21

Preferisco lo stile tra parentesi, principalmente perché dà agli occhi un chiaro punto di inizio e fine.Rende più semplice vedere cosa è effettivamente contenuto nell'istruzione e che in realtà si tratta di un'istruzione if.Una piccola cosa, forse, ma è per questo che lo uso.

Answer 22

fintanto che è coerente all’interno del team in cui lavori, non ha molta importanza

che tutti facciano lo stesso è la cosa principale

Answer 23

Mettere tra parentesi le tue istruzioni if ​​di una riga ha il notevole vantaggio di proteggerti dai mal di testa se, in un secondo momento, tu (o altri programmatori che mantengono o alterano il tuo codice) dovete aggiungere istruzioni a qualche parte di quel blocco condizionale.

Answer 24

Se fai qualcosa del genere:

if(x)
{
    somecode;
}
else
{
    morecode;
}

Questo funziona meglio per il controllo delle origini e le direttive preprocessore sul codice che vive a lungo.È più facile aggiungere un #se o giù di lì senza rompere inavvertitamente la dichiarazione o dover aggiungere linee extra.

È un po 'strano abituarsi, ma funziona abbastanza bene dopo un po'.

Answer 25

Se è una riga di if (e facoltativamente una riga di else) preferisco non utilizzare le parentesi.È più leggibile e conciso.Dico che lo preferisco perché è puramente una questione di preferenza.Anche se penso che cercare di imporre uno standard secondo cui devi sempre usare l'apparecchio è un po' sciocco.

Se devi preoccuparti che qualcuno aggiunga un'altra riga al corpo dell'istruzione if e non aggiunga le parentesi graffe (solo allora richieste), penso che tu abbia problemi più grandi rispetto agli standard di codifica sub-bizantini.

Answer 26

/* I type one liners with brackets like this */
if(0){return(0);}
/* If else blocks like this */
if(0){
    return(0);
}else{
    return(-1);
}

Non utilizzo mai spazi bianchi superflui oltre le tabulazioni, ma includere sempre le parentesi mi fa risparmiare un sacco di tempo.

Answer 27

Non mi piace chiudere le parentesi graffe sulla stessa riga con la parola chiave seguente:

if (x) {
    print "x is true";    
} else {
    do something else;
}

Ciò rende più difficile rimuovere/commentare solo la clausola else.Inserendo la parola chiave follow nella riga successiva, posso trarre vantaggio, ad esempio, dagli editor che mi consentono di selezionare un intervallo di righe e di commentarle/decommentarle tutte in una volta.

if (x) {
    print "x is true";    
}
//else {
//    do something else;
//}

Answer 28

Preferisco sempre questo:

if (x) doSomething();

if (x) {
    doSomthing();
    doOtherthing();
}

Ma dipende sempre dalla lingua e dalle azioni che stai facendo.A volte mi piace mettere l'apparecchio, a volte no.Dipende dal codice, ma io codifico come se dovessi scrivere una volta, riscrivere dieci volte e leggere cento volte;quindi, fallo come vuoi e come vuoi leggere e capire più velocemente

Answer 29

Non importa cosa, questo è il modo in cui vado!Sembra il migliore.

If(x)
{
    print "Hello World !!"
}
Else
{
    print "Good bye!!"
}

Answer 30

Se sei curioso di sapere quali sono i nomi dei vari stili di formattazione del codice, Wikipedia ha un articolo su Stili di rientro.