"// ..." commenti alla fine del blocco di codice dopo} - buono o cattivo? [chiuso]

Direi che se il tuo codice è così lungo che non puoi seguire facilmente le tue parentesi, il tuo codice ha bisogno di refactoring, per la maggior parte delle lingue.

Tuttavia, nei linguaggi dei template (come PHP) potrebbe essere valido, perché potresti avere un grande blocco di HTML che separa l'inizio e la fine della condizione o della struttura del ciclo.

È un odore di codice e di solito è un post-sbornia di stile di codice vecchio stile. Prima che il refactoring degli IDE decenti fosse più difficile e non così comune come ora, i metodi erano più lunghi e questi commenti erano lì per aiutarli a navigare meglio.

Questa è una pratica orribile resa obsoleta da molti fattori.

• Gli IDE più moderni evidenziano la parentesi corrispondente quando il cursore si trova su uno dei due simboli.
• Se stai codificando in modo pulito, raramente troverai un posto dove il tuo metodo è più di 10 righe.

Ho notato che molti programmatori Java hanno questa mentalità e rendono il codice Java molto sporco e distoglie l'attenzione dal codice e dai commenti.

Altamente suggerisci di non usare questo.

Il codice viene letto 10 volte di più di quello che è scritto.

Se facilita la lettura, fallo.

Suggerirei anche a chiunque lo facesse di guardare in altri modi per rendere le cose più facili da leggere. Le tecniche di refactoring, le parentesi su linee diverse, ecc. Che altre persone hanno menzionato sono tutte buone. Anche dividere le cose in diverse funzioni, metodi o classi in modo che il codice sia auto-commentante è anche un bene. Ci sono anche modi per eliminare la maggior parte dei "se" e mettere "per" i loop in posti ovvi, eliminando così la necessità di tutto ciò.

Ma a volte le persone stanno imparando. Se questo è qualcosa che stanno facendo, questo rende veramente il codice più leggibile, lo incoraggia e poi incoraggia anche altre pratiche. Le persone che stanno imparando meritano e beneficeranno di incoraggiamento, indipendentemente da come iniziano. Dire "Questo è male" non è così utile come dire "Quest'altra cosa è meglio".

Ho una grande base di codice (C ++) piena di questo tipo di cose:

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

Per qualcosa di così piccolo, direi che va oltre il "code smell" in "code puzza". Soprattutto in un IDE in cui posso abbinare il tutore di chiusura con una sequenza di tasti per trovare il tutore di apertura. Dato un metodo più lungo, continuerò a utilizzare la parentesi graffa sul commento del terminale. Tali commenti mi distraggono e tendo a considerarli come un rumore.

In C ++ ci sono due holdover in cui questo è ancora utile e il consiglio di "dividere il tuo codice" non è necessario:

1. Per gli spazi dei nomi. Uno spazio dei nomi può comprendere un intero file e l'ultima parentesi può a volte allontanare le persone, quindi aggiungere un commento per indicare che la parentesi è la chiusura di uno spazio dei nomi è utile. Per il particolare stile di codifica della mia azienda questo è importante perché non indentiamo spazi dei nomi in quanto è stato deciso che tale indentazione avrebbe semplicemente sprecato spazio in un file.

2. Per le coppie #ifdef / #endif. A volte c'è un sacco di codice per la compilazione condizionale, può diventare sgradevole con il nesting, e l'editor che usiamo spesso "utilmente" pesantemente elimina il rientro, quindi i commenti sono utili durante una rapida panoramica.

Per me il codice deve essere confuso per aggiungere un commento come quello che hai specificato.

Se dice solo // istruzione IF. Quindi devi chiederti perché è lì, in primo luogo.

L'alternativa a vedere che cosa sta chiudendo il tutore è avere quella di apertura sulla stessa colonna di quella stretta. Lo trovo molto più chiaro e più leggibile.

Il commento è utile quando normalmente sarebbe difficile da rintracciare perché l'open è successo molto tempo fa. Questo dovrebbe normalmente accadere solo per uno spazio dei nomi (in particolare l'anonimo in C ++, usato per i dettagli di implementazione nell'unità di compilazione). Nella maggior parte degli altri casi dovrebbe essere ovvio cosa stai chiudendo.

Questo è in gran parte un retaggio dei vecchi tempi di lavoro con finestre di terminale a caratteri 80x24, specialmente se si stesse usando un editor con finestra come EVE. Anche adesso, faccio la maggior parte del mio lavoro in una sessione di terminale usando vim, e posso dividere la sessione in tre o quattro sottofinestre, quindi posso solo vedere veramente poche righe in qualsiasi momento.

Detto questo, non ho mai veramente scaldato la convention, anche se mi avrebbe salvato la pancetta in più di un'occasione. Lo vedo solo come rumore. Se i tuoi loop o condizionali stanno diventando così grandi, si, potresti voler esaminare il refactoring.

in pratica dai tutti i validi motivi per non usarlo. Ogni programmatore decente dovrebbe applicarli. Quindi perché le persone fanno lo usano? Perché stanno facendo male e non sanno meglio.

Rientra invece il dannato codice. (Stai già facendo questo non sei ???!) Nessun problema, nessuna preoccupazione, nessun commento non aggiornato, nessuna manutenzione extra.