uso obbligatorio di bretelle

Question

Come parte di un documento standard di codice che ho scritto un po 'indietro, ho far rispettare "si deve sempre utilizzare le parentesi per i cicli e / o blocchi di codice condizionali, anche (soprattutto) se sono solo una riga."

Esempio:

// this is wrong
if (foo) 
    //bar
else 
    //baz
while (stuff)
    //things

// This is right.
if (foo) {
    // bar
} else {
    // baz
}
while (things) {
    // stuff
}

Quando non si prepari una sola linea, e poi qualcuno commenta fuori, sei nei guai. Se non si prepari una sola riga, e il rientro non visualizza lo stesso sulla macchina di qualcun altro ... che sei nei guai.

Quindi, Domanda: Ci sono buone ragioni per cui questa sarebbe una norma sbagliata o in altro modo irragionevole? C'è stata qualche discussione su di esso, ma nessuno mi può offrire una contro-meglio di "E 'brutto".

Answer 1

I rispettare questa ad un punto, tranne rari casi perché se le dichiarazioni che valutano a uno tornare o continuare un ciclo.

Quindi, questo è corretto per il mio standard:

if(true) continue;

Come è questo

if(true) return;

Ma la regola è che si tratta sia di un ritorno o continuare, ed è tutto sulla stessa linea. In caso contrario, bretelle per tutto.

Il ragionamento è tanto per il gusto di avere un modo standard di farlo, e per evitare il problema commentando lei ha citato.

Answer 2

Il miglior argomento contatore che posso offrire è che la linea in più (s) ripreso dallo spazio ridurre la quantità di codice è possibile visualizzare in una sola volta, e la quantità di codice è possibile visualizzare in una sola volta è un grande fattore in quanto è facile da individuare gli errori. Sono d'accordo con le ragioni che hai dato per l'inclusione di parentesi graffe, ma in tanti anni di C ++ mi viene in mente solo una volta, quando ho fatto un errore come risultato ed è stato in un posto dove ho avuto nessun buon motivo per saltare le parentesi graffe Comunque. Purtroppo non saprei dire se vedere quelle linee di codice extra mai aiutato in pratica oppure no.

Sono forse più prevenuto perché mi piace la simmetria di corrispondenza tra parentesi allo stesso livello di indentazione (e il raggruppamento implicito delle affermazioni contenute come un blocco di esecuzione) - il che significa che le parentesi aggiungendo tutti il tempo aggiunge un sacco di linee al progetto.

Answer 3

Vedo questa regola come eccessivo. norme draconiane non fanno buoni programmatori, che hanno appena diminuiscono le probabilità che uno slob sta andando a fare un pasticcio.

Gli esempi che date sono valide, ma hanno soluzioni migliori rispetto costringendo parentesi:

  

Quando non si prepari una sola linea, e poi qualcuno commenta fuori, sei nei guai.

Due pratiche risolvere questo meglio, scegliere uno:

1) Commentare la if, while, ecc prima che l'one-liner con l'one-liner. Cioè trattare

if(foo)
    bar();

come qualsiasi altra dichiarazione multi-linea (ad esempio un'assegnazione con linee multiple, o una chiamata di funzione con più righe):

//if(foo)
//    bar();

2) precedere il // con un ;:

if(foo)
;//    bar();

  

Se non si prepari una sola riga, e il rientro non visualizza lo stesso sulla macchina di qualcun altro ... che sei nei guai.

No, non lo sei; il codice funziona lo stesso, ma è più difficile da leggere. Correggi il tuo rientro. Scegliere le schede o gli spazi e bastone con loro. Non mescolare le schede e gli spazi per l'indentazione. molti editor di testo risolverà automaticamente questo per voi.

scrivere del codice Python. Che risolverà almeno alcune abitudini di rientro cattive.

Inoltre, strutture come } else { apparire come una versione nethack di un caccia TIE per me.

  

Ci sono buone ragioni per cui questo sarebbe uno standard scambiati o in altro modo irragionevole? C'è stata qualche discussione su di esso, ma nessuno mi può offrire una contro-meglio di "E 'brutto".

parentesi ridondanti (e parentesi) sono l'ingombro visivo. Visiva disordine rende il codice più difficile da leggere. Il codice più difficile è quello di leggere, più facile è quello di nascondere i bug.

int x = 0;
while(x < 10);
{
    printf("Count: %d\n", ++x);
}

Forzare parentesi non aiutare a trovare il bug nel codice di cui sopra.

P.S. Sono un abbonato al "ogni regola deve dire perché" la scuola, o come il Dalai Lama ha messo, "Conoscere le regole in modo che si può correttamente romperli".

Answer 4

devo ancora avere qualcuno venire con una buona ragione per non usare sempre le parentesi graffe.

I benefici superano di gran lunga qualsiasi "E 'brutto" ragione che ho sentito.

standard di codifica esistono per rendere il codice più facile da leggere e ridurre gli errori.

Questo è uno standard che paga veramente fuori.

Answer 5

Trovo difficile discutere con gli standard di codifica che riducono gli errori e rendere il codice più leggibile. Si può sentire brutto per alcune persone in un primo momento, ma penso che sia una regola perfettamente valida per implementare.

Answer 6

io sto con la motivazione che le parentesi graffe dovrebbe corrispondere in base alla indentazione.

// This is right.
if (foo) 
{
    // bar
}
else 
{
    // baz
}

while (things) 
{
    // stuff
}

Per quanto riguarda i vostri due esempi, mi piacerebbe prendere in considerazione la vostra un po 'meno leggibile dato che trovare l'abbinamento chiusura parentesi può essere difficile, ma più leggibile nei casi in cui non è corretta indentazione, pur consentendo la logica da inserire più facile. Non è una differenza enorme.

Anche se il rientro non è corretta, l'istruzione if eseguirà il comando successivo, a prescindere dal fatto che sia nella riga successiva oppure no. L'unica ragione per non mettere entrambi i comandi sulla stessa linea è per supporto debugger.

Answer 7

L'unico grande vantaggio che vedo è che è più facile aggiungere ulteriori dichiarazioni condizionali e loop che sono rinforzati, e non ci vuole molte combinazioni di tasti aggiuntivi per creare le parentesi alla partenza.

Answer 8

La mia regola personale è se si tratta di un brevissimo 'se', poi mettere il tutto su una riga:

if(!something) doSomethingElse();

In genere io uso questo solo quando ci sono un sacco di IFS come questo in successione.

if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);

Questa situazione non si verifica molto spesso, però, quindi in caso contrario, ho sempre utilizzare le parentesi graffe.

Answer 9

Al momento, io lavoro con una squadra che vive di questo standard, e, mentre io sono resistenti ad esso, di ottemperare per il bene di uniformità.

Mi oppongo per lo stesso motivo mi oppongo alle squadre che vietano l'uso di eccezioni o modelli o le macro:. Se si sceglie di utilizzare una lingua, utilizzare l'intero linguaggio Se le parentesi graffe sono opzionali in C e C ++ e Java, li mandato per convenzione mostra una certa paura del linguaggio stesso.

Capisco i rischi descritti nella altre risposte qui, e capisco il desiderio di uniformità, ma io non sono in sintonia con lingua subsetting Blocco qualche rigoroso ragione tecnica , come ad esempio l'unico compilatore per un po 'l'ambiente non possono ospitare modelli o l'interazione con il codice C precludendo ampio utilizzo delle eccezioni.

Gran parte della mia giornata si compone di rivedere le modifiche presentate dai programmatori junior, ed i problemi comuni che si verificano non hanno nulla a che fare con il posizionamento tutore o dichiarazioni di liquidazione nel posto sbagliato. Il pericolo è esagerata. Preferisco spendere il mio tempo concentrandosi su più problemi materiali che alla ricerca di violazioni di ciò che il compilatore avrebbe felicemente accettare.

Answer 10

L'unico modo standard di codifica può essere seguito anche da un gruppo di programmatori è quello di mantenere il numero di regole al minimo.

Bilanciare il vantaggio contro il costo (ogni regola in più confonde e confonde i programmatori, e dopo una certa soglia, in realtà riduce la possibilità che i programmatori seguiranno una delle regole)

Quindi, per fare uno standard di codifica:

• Assicurarsi che si può giustificare ogni regola con chiara evidenza che è meglio rispetto alle alternative.

• Guarda alternative alla regola - è davvero necessaria? Se tutti i programmatori di utilizzare gli spazi (righe vuote e indentazione) bene, un'istruzione if è molto facile da leggere, e non c'è modo che anche un programmatore alle prime armi può confondere una dichiarazione all'interno di un "se" per una dichiarazione che è standalone. Se hai trovato un sacco di bug relativi alla se-scoping, la causa principale è probabilmente che si dispone di un povero whitepsace / stile di rientro che rende il codice inutilmente difficile da leggere.

• Dare priorità le regole per il loro effetto misurabile sulla qualità del codice. Quanti errori si può evitare facendo rispettare una regola (ad esempio "controllare sempre per nulla", "sempre validare i parametri con un'asserzione", "sempre scrivere uno unit test" contro "sempre aggiungere alcune coppie, anche se non sono necessari") . Gli ex regole vi farà risparmiare migliaia di insetti un anno. La regola tutore si potrebbe salvare uno. Forse.

• mantenere le regole più efficaci, ed eliminare la pula. Pula è, come minimo, qualsiasi regola che vi costerà di più per implementare rispetto eventuali bug che potrebbero verificarsi ignorando la regola. Ma probabilmente se si dispone di più di circa 30 regole fondamentali, i tuoi programmatori ignorerà molti di loro, e le vostre buone intenzioni sarà come la polvere.

• Fuoco ogni programmatore che commenta le bit casuali di codice senza leggerlo: -)

P.S. La mia posizione sul rinforzo è: se la "if" o il contenuto di esso sono sia una singola linea, allora si può omettere le parentesi. Ciò significa che se si dispone di un if contenente un commento di una riga ed una sola riga di codice, i contenuti prendere due linee, e quindi sono richieste parentesi. Se la condizione se si estende su due linee (anche se il contenuto di una singola linea), allora avete bisogno di parentesi graffe. Questo significa che si omette solo bretelle in banali, casi semplici, facilmente leggere dove gli errori non sono mai nell'attività lavorativa. (Quando una dichiarazione è vuoto, io non uso le parentesi graffe, ma ho sempre messo un commento affermando chiaramente che è vuota, e volutamente così, ma questo è confinante con un argomento diverso:. Essere esplicita nel codice in modo che i lettori sappiano che si intende un ambito di essere vuota piuttosto che il telefono ha squillato e si è dimenticato di finire il codice)

Answer 11

Molti languanges hanno una sintassi per uno liners come questo (sto pensando di Perl in particolare) a che fare con tale "bruttezza". Quindi, qualcosa di simile a:

if (foo)     
//bar
else     
//baz

può essere scritta come un ternario utilizzando l'operatore ternario:

foo ? bar : baz

e

while (something is true)
{
blah 
}

può essere scritta come:

blah while(something is true)

Tuttavia in lingue che non hanno questo "zucchero" Vorrei assolutamente includere le parentesi graffe. Come hai detto tu impedisce bug inutili da strisciante e rende l'intenzione del programmatore più chiara.

Answer 12

Non sto dicendo che è irragionevole, ma in 15 anni di codifica con i linguaggi C-like, non ho avuto un solo problema con omettendo le parentesi graffe. Commentando un ramo suona come un vero problema in teoria -. Ho appena mai visto accadendo in pratica

Answer 13

Un altro vantaggio di utilizzare sempre parentesi è che rende la ricerca e sostituzione e operazioni automatizzate analoghe esigenze.

Ad esempio: Supponiamo che io noto che functionB viene di solito chiamato immediatamente dopo functionA, con un modello simile di argomenti, e quindi voglio refactoring che duplicare il codice in un nuovo combined_function. Un'espressione regolare potrebbe facilmente gestire questo refactoring se non si dispone di un potente strumento abbastanza refactoring (^\s+functionA.*?;\n\s+functionB.*?;), ma, senza bretelle, un approccio semplice espressione regolare potrebbe fallire:

if (x)
  functionA(x);
else
  functionA(y);
functionB();

sarebbe diventato

if (x)
  functionA(x);
else
  combined_function(y);

espressioni regolari più complesse funzionerebbero in questo caso particolare, ma ho trovato molto utile per essere in grado di utilizzare regex-based di ricerca e sostituzione, una tantum script Perl, e simili manutenzione del codice automatizzato, quindi preferisco uno stile di codifica che non fa che inutilmente complicato.

Answer 14

Non compro nel vostro argomento. Personalmente, io non conosco nessuno che sia mai "accidentalmente", ha aggiunto una seconda linea sotto un if. Vorrei capire dicendo che annidati dichiarazioni if dovrebbe avere bretelle per evitare un penzoloni altro, ma come la vedo io sei imporre uno stile a causa di una paura che, IMO, è fuori luogo.

Answer 15

Qui ci sono le scritte (fino ad ora suppongo) regole che passano. Credo che fornisce la leggibilità senza sacrificare la correttezza. Si basa sulla convinzione che la forma breve è in parecchi casi più leggibile rispetto alla forma a lungo.

• Usare sempre le parentesi se qualsiasi blocco della dichiarazione if/else if/else ha più di una riga. contano i commenti, il che significa un commento in qualsiasi parte del mezzo condizionato tutte le sezioni del condizionale ottenere parentesi graffe.
• Opzionalmente usare le parentesi quando tutti blocchi della dichiarazione sono esattamente una riga.
• Non posizionare l'istruzione condizionale sulla stessa riga della condizione. La linea dopo l'istruzione if è sempre condizionato eseguita.

• Se l'istruzione condizionale in sé esegue l'azione necessaria, il modulo sarà:

  for (init; term; totalCount++)
  {
      // Intentionally left blank
  }
  

Non c'è bisogno di standardizzare questo in un modo dettagliato, quando si può semplicemente dire quanto segue:

  

Non lasciare mai parentesi a spese di leggibilità. In caso di dubbio, scegliere di utilizzare le parentesi graffe.

Answer 16

Credo che la cosa importante di parentesi graffe è che molto sicuramente esprimono l'intento del programmatore. Non si dovrebbe avere di individuare la volontà da rientro.

Detto questo, mi piacciono i rendimenti a riga singola e continua suggerito da Gus. L'intento è evidente, ed è più pulito e più facile da leggere.

Answer 17

Se avete il tempo di leggere attraverso tutto questo, allora si ha il tempo di aggiungere le parentesi extra.

Answer 18

Io preferisco parentesi aggiungendo alla condizionali single-line per manutenzione, ma posso vedere come farlo senza bretelle sembra più pulito. Non mi dà fastidio, ma alcune persone potrebbe essere spento dal rumore visivo in più.

Non riesco a offrire un contro-meglio neanche. Scusate! ;)

Answer 19

Per le cose come questo, mi sento di raccomandare solo venire con un modello di configurazione per autoformatter del vostro IDE. Quindi, ogni volta che gli utenti hanno colpito alt-shift-F (o qualunque sia la combinazione di tasti è nel vostro IDE di scelta), saranno aggiunte automaticamente le parentesi graffe. Poi basta dire a tutti: ". Andare avanti e cambiare il tipo di carattere da colorare, impostazioni PMD o qualsiasi altra cosa Si prega di non cambiare le regole i rientri o auto-brace, anche se"

Questa sfrutta gli strumenti a nostra disposizione per evitare di discutere su qualcosa che non è davvero la pena l'ossigeno che è normalmente speso su di esso.

Answer 20

A seconda sul lingua , con bretelle per una singola istruzione condizionale foderato o istruzione del ciclo non è obbligatorio. In effetti, vorrei togliere loro di avere un minor numero di linee di codice.

C ++:

Versione 1:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 ) throw InvalidOperation();
   return a/b;
}

Versione 2:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 )
   { 
      throw InvalidOperation();
   }
   return a/b;
}

C #:

Versione 1:

foreach(string s in myList)
   Console.WriteLine(s);

Version2:

foreach(string s in myList)
{
   Console.WriteLine(s);
}

A seconda del vostro punto di vista, la versione 1 o versione 2 sarà più leggibile. La risposta è piuttosto soggettivo .

Answer 21

Wow. NESSUNO è a conoscenza del penzoloni altro problema ? Si tratta essenzialmente di L ' ragione di sempre usare le parentesi.

In poche parole, si può avere brutto logica ambigua con else, soprattutto quando sono annidati. Diversi compilatori risolvere l'ambiguità a modo loro. Può essere un problema enorme di lasciare fuori le parentesi se non si sa cosa si sta facendo.

L'estetica e la leggibilità ha nulla a che fare.