“//…” commenti alla fine del blocco di codice dopo} - buoni o cattivi? [chiuso]

Ho visto spesso usare tali commenti:

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

e talvolta anche fino a

if (condition) {
   ...
} // if (condition)

Non ho mai capito questa pratica e quindi non l'ho mai applicata. Se il tuo codice è così lungo che devi sapere qual è questo finale, }forse dovresti considerare di dividerlo in funzioni separate. Inoltre, la maggior parte degli strumenti per sviluppatori è in grado di passare alla parentesi corrispondente. E infine l'ultimo è, per me, una chiara violazione del principio DRY; se cambi la condizione dovresti ricordarti di cambiare anche il commento (altrimenti potrebbe diventare disordinato per il manutentore, o anche per te).

Quindi perché la gente lo usa? Dovremmo usarlo o è una cattiva pratica?

Direi che se il tuo codice è così lungo che non riesci a seguire facilmente le parentesi graffe, il tuo codice deve essere sottoposto a refactoring, per la maggior parte delle lingue.

Tuttavia, nei linguaggi di 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 una sbornia dallo stile di codice vecchio stile. Prima che il refactoring di IDE decenti fosse più difficile e non così comune come lo è ora, quindi i metodi erano più lunghi e questi commenti erano lì per aiutare a navigare meglio.

Questa è una pratica orribile resa obsoleta da molti fattori.

• Gli IDE più moderni evidenziano la parentesi graffa corrispondente quando il cursore è su entrambi i simboli.
• Se stai programmando in modo pulito, raramente troverai un posto in cui il tuo metodo è più di 10 righe.

Ho notato che molti programmatori Java hanno questa mentalità, e rende il codice Java davvero sporco e distoglie l'attenzione dal codice e verso i commenti.

Consiglio vivamente di non usarlo.

Il codice viene letto 10 volte di più di quanto sia scritto.

Se facilita la lettura, fallo.

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

Ma a volte le persone stanno imparando. Se questo è qualcosa che stanno facendo, sta davvero rendendo il codice più leggibile, incoraggiandolo e quindi incoraggiando anche altre pratiche. Le persone che stanno imparando meritano e trarranno beneficio dall'incoraggiamento, indipendentemente da come iniziano. Dire "Questo è male" non è utile come dire "Quest'altra cosa è migliore".

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

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

Per qualcosa di così piccolo, direi che va oltre "odore di codice" in "puzza di codice". Soprattutto in un IDE dove posso abbinare la parentesi graffa di chiusura con una sequenza di tasti per trovare la parentesi graffa di apertura. Dato un metodo più lungo, prenderò ancora la parentesi graffa sul commento del terminale. Tali commenti mi distraggono e tendo a pensarli come rumore.

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

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

2. Per coppie #ifdef / #endif. A volte c'è un sacco di codice lì dentro per la compilazione condizionale, può diventare sgradevole con l'annidamento e l'editor che usiamo spesso in modo pesantemente "utile" 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 semplicemente // Dichiarazione IF. Quindi devi chiederti perché è lì in primo luogo.

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

Il commento è utile quando normalmente sarebbe difficile da rintracciare perché l'apertura è avvenuta molto tempo fa. Ciò dovrebbe avvenire normalmente solo per uno spazio dei nomi (in particolare quello anonimo in C ++, utilizzato 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 problema dai vecchi tempi di lavoro nelle finestre dei terminali 80x24 caratteri, soprattutto se si utilizzava un editor con finestre come EVE. Anche ora, faccio la maggior parte del mio lavoro in una sessione terminale usando vim, e posso dividere la sessione in tre o quattro finestre secondarie, quindi posso davvero vedere solo poche righe alla volta.

Detto questo, non mi sono mai veramente riscaldato alla 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, sì, potresti voler esaminare il refactoring.

in pratica dai tutti i motivi validi per non usarlo. Ogni programmatore decente dovrebbe applicarli. Allora, perché non la gente lo usa? Perché stanno sbagliando e non sanno meglio.