Devo usare identificatori di blocco ("end;") nel mio codice?

Question

Code Complete dice che è buona norma per sempre utilizzare identificatori di blocco, sia per chiarezza che come misura difensiva.

Da quando ho letto quel libro, lo sto facendo religiosamente. A volte sembra eccessivo, come nel caso qui sotto.

È Steve McConnell giusto insistere per utilizzare sempre identificatori di blocco? Quale di questi useresti?

//naughty and brief 
with myGrid do 
    for currRow := FixedRows to RowCount - 1 do 
    if RowChanged(currRow) then 
     if not(RecordExists(currRow)) then 
     InsertNewRecord(currRow) 
     else 
     UpdateExistingRecord(currRow); 

//well behaved and verbose 
with myGrid do begin 
    for currRow := FixedRows to RowCount - 1 do begin 
    if RowChanged(currRow) then begin 
     if not(RecordExists(currRow)) then begin 
     InsertNewRecord(currRow); 
     end //if it didn't exist, so insert it 
     else begin 
     UpdateExistingRecord(currRow); 
     end; //else it existed, so update it 
    end; //if any change 
    end; //for each row in the grid 
end; //with myGrid 

Answer 1

Personalmente, preferisco il primo, come IMHO la "fine"; non dirmi molto, e una volta che tutto è vicino, posso dire dall'identificazione cosa succede quando.

Credo che i blocchi siano più utili quando si hanno dichiarazioni di grandi dimensioni. Potresti fare un approccio misto, in cui inserisci alcuni "begin ... end;" e commenta cosa stanno finendo (per esempio usalo per il con e il primo se).

IMHO si potrebbe anche spezzare questo in più metodi, per esempio, la parte

if not(RecordExists(currRow)) then begin 
    InsertNewRecord(currRow); 
    end //if it didn't exist, so insert it 
    else begin 
    UpdateExistingRecord(currRow); 
    end; //else it existed, so update it 

potrebbe essere in un metodo separato.

Answer 2

Ho sempre seguito la ' ben educati e verbose' lo stile, ad eccezione di quei commenti aggiuntivi non necessari ai blocchi finali.

In qualche modo ha più senso essere in grado di guardare il codice e capire da esso più velocemente, piuttosto che dover passare almeno un paio di secondi prima di decifrare quale blocco finisce dove.

Tip Visual Studio collegamento KB per C# salto inizio e fine: Ctrl +]

Se si utilizza Visual Studio, quindi avere parentesi graffe per C# all'inizio e alla fine del blocco aiuta anche dal fatto che hai una scorciatoia KB da saltare per iniziare e terminare

Answer 3

Vorrei usare la mia azienda per i suoi standard di codifica.

Detto questo, preferirei utilizzare il secondo blocco, più dettagliato. È molto più facile da leggere. Tuttavia, in alcuni casi, potrei lasciare i commenti a chiusura di blocco.

Answer 4

Se ricordo male, CC ha anche fornito alcuni consigli sui commenti. Soprattutto per non riscrivere lo il codice nei commenti, ma spiegare perché lo fa.

Answer 5

Direi che ha ragione solo per il fatto che il codice può ancora essere interpretato correttamente se il rientro è errato. Mi piace sempre essere in grado di trovare gli identificatori dei blocchi di inizio e di fine per i loop quando sfoglio il codice e non mi baso sul rientro corretto.

Answer 6

Non è mai sempre in un modo o nell'altro. Perché mi fido di me stesso, userei lo stile più breve e più teso. Ma se sei in un ambiente di squadra in cui non tutti hanno la stessa competenza e la manutenibilità è importante, potresti decidere di optare per quest'ultimo.

Answer 7

Gli identificativi di blocco non sono solo più facili da leggere, sono molto meno soggetti a errori se si sta modificando qualcosa nella logica if else o semplicemente aggiungendo una riga e non riconoscendo che la linea non si trova nello stesso blocco logico quindi resto del codice.

Vorrei utilizzare il secondo blocco di codice. La prima sembra più carina e più familiare, ma penso che questo sia un problema della lingua e non degli identificatori di blocco

Se è possibile, io uso il checkstyle per garantire che vengano utilizzate le parentesi.

Answer 8

commentando la fine è davvero utile per le lingue html-like così fanno codice C malformati come una successione infinita di if/else/if/else

Answer 9

frequenti // commenti alla fine di righe di codice (per il vostro bene Behaved e Verbose esempio) rendono il codice più difficile da leggere imho - quando lo vedo, finisco con lo scannerizzare i commenti "ovvi" formando qualcosa di speciale che in genere non c'è.

preferisco commenti solo quando l'ovvio non è (vale a dire in generale e/o funzionalità uniche)

Answer 10

Penso che dipende un po 'dalla situazione. A volte è sufficiente avere un metodo come questo:

void Foo(bool state) 
{ 
    if (state) 
     TakeActionA(); 
    else 
     TakeActionB(); 
} 

Io non vedo come facendolo apparire come questo:

void Foo(bool state) 
{ 
    if (state) 
    { 
     TakeActionA(); 
    } 
    else 
    { 
     TakeActionB(); 
    } 
} 

migliora la leggibilità a tutti.

Answer 11

La mia reazione istintiva sarebbe il secondo elenco (con i commenti ripetitivi rimossi dalla fine delle righe, come tutti hanno detto), ma dopo averci pensato più profondamente, sarei andato con il primo più uno o un commento utile di due righe in anticipo che spiega cosa sta succedendo (se necessario). Ovviamente in questo esempio di giocattolo, anche il commento prima della risposta concisa non sarebbe probabilmente necessario, ma in altri esempi potrebbe.

Avere meno (ma comunque leggibile) e codice di facile comprensione sullo schermo aiuta a mantenere lo spazio del cervello libero per le parti future del codice IMO.

Answer 12

Sono uno sviluppatore Python, quindi non vedo la necessità di identificatori di blocchi. Sono abbastanza felice senza di loro. L'indentazione è sufficiente per me.

Answer 13

Sono con quelli che preferiscono il codice più conciso.

E sembra preferire una versione verbosa a una concisa è più una scelta personale, che di una convenienza universale. (Beh, all'interno di un'azienda può diventare una regola (mini-) universale.)

È come una parentesi eccessiva: alcune persone lo preferiscono come (F1 and F2) or ((not F2) and F3) o (A - (B * C)) < 0 e non necessariamente perché non conoscono le regole di precedenza. È solo più chiaro per loro in questo modo.

Answer 14

voto per un mezzo felice. La regola che userei è usare le parole chiave del bracketing ogni volta che il contenuto è composto da più righe. In azione:

// clear and succinct 
with myGrid do begin 
    for currRow := FixedRows to RowCount - 1 do begin 
    if RowChanged(currRow) then begin 
     if not(RecordExists(currRow)) 
     InsertNewRecord(currRow); 
     else 
     UpdateExistingRecord(currRow); 
    end; // if RowChanged 
    end; // next currRow 
end; // with myGrid 

Answer 15

Personalmente vi consiglio di usare sempre gli identificatori di blocco in lingue che li sostengono (ma seguire gli standard di codifica della vostra azienda, come suggerisce @ Muad'Dib).

La ragione è che, in lingue non Pythonic, lo spazio bianco è (generalmente) non significativo per il compilatore ma è per gli esseri umani.

Così

with myGrid do 
    for currRow := FixedRows to RowCount - 1 do 
    if RowChanged(currRow) then 
     Log(currRow); 
     if not(RecordExists(currRow)) then 
     InsertNewRecord(currRow) 
     else 
     UpdateExistingRecord(currRow);    

sembra di fare una cosa, ma fa qualcosa di molto diverso.

Eliminerei comunque i commenti di fine linea. Usa un IDE che evidenzia i blocchi. Penso che lo Castalia lo farà per Delphi. Quanto spesso leggi le stampe di codici?