Commenti divisionali / sezionali, buoni o cattivi?

7

Conosco la tendenza generale contro i commenti che spiegano come funziona qualcosa, e come sia una buona idea usarli solo per spiegare perché stai facendo quello che stai facendo, ma come usare i commenti come mezzo per dividere il codice?

Supponi di avere uno script che fa un preambolo, cerca in un gruppo di record, stampa i record, quindi chiude tutto:

// Preamble
... preamble code, say about 10-15 lines ...

// Find records
... sql query ...
... put records into array ...
... some other stuff ...

// Print records
... printing records, 20-30 lines a record ...

// Close everything
...

Più di un modo per dividere visivamente il codice, semplificare la ricerca di una determinata sezione. Come se in un mese fosse necessario correggere il codice di stampa, piuttosto che leggere centinaia di righe per cercare di trovare il punto giusto, basta guardare i commenti per vedere dove si trova.

Ciò che effettivamente accade in ogni sezione è abbastanza semplice e facile da dire cosa sta succedendo, questo approccio ai commenti dovrebbe essere considerato buono o cattivo ?

Modifica Sto lavorando principalmente con script PHP, in cui non è possibile inserire il codice in funzioni o è poco pratico farlo. Tuttavia, lo stesso tipo di cosa si applica ai file di grandi dimensioni, con diversi metodi che fanno cose correlate, come getter / setter, aggiornamenti del database, ecc.

    
posta Tarka 10.11.2010 - 16:14
fonte

6 risposte

8

Non sono fuori e fuori di testa, ma ti chiederei se la tua routine è così lunga da avere sezioni significative di per sé e che hai bisogno di un commento non sarebbe meglio scomporle in routine più piccole?

Avresti quindi una routine di primo livello che era totalmente leggibile senza commenti:

Thing.Initialise
Thing.PopulateFromDatabase
Thing.PrintResults
Thing.ShutDown

Inoltre ora è tutto riutilizzabile.

Aggiungo anche che in generale cose come "chiudere tutto" dovrebbero essere ovvie dal codice e dalla struttura e quindi non necessarie. Se il codice è This.Close (), That.CleanUp (), TheOther.Disconnect (), in realtà non è necessario un commento che spieghi.

Dove penso che questo tipo di commenti siano validi è in grado di sgrossare il tuo design e la struttura prima di iniziare. Trovo bello scrivere la cosa in pseudo codice nei commenti e quindi rimuoverli mentre in realtà lo codifico. Puoi quindi aggiungere e modificare rapidamente il design durante la codifica senza il rischio di dimenticare ciò che avevi deciso.

    
risposta data 10.11.2010 - 16:23
fonte
7

Mi piace questo tipo di commenti. Non tutti i fattori si inseriscono bene in una classe o funzione separata. Ad esempio, se dovessi passare quasi l'intero valore dello stack frame a una funzione / classe di questo tipo, non stai davvero disaccoppiando / semplificando nulla prendendo in considerazione il codice. Anche se il codice può essere scomposto, ciò non significa che dovrebbe essere. Devi valutare i guadagni di riutilizzabilità e i guadagni di leggibilità dei singoli passaggi rispetto al fatto che l'eccessiva indiretta può rendere più opaco il flusso complessivo del codice.

Anche se si separa il codice in una classe / funzione, i commenti potrebbero talvolta essere utili per spiegare ad un livello elevato che cosa fa il codice. I commenti non sostituiscono il codice leggibile, ma anche il codice leggibile non riassume sempre il suo scopo di alto livello, anche se è ben curato in piccole funzioni / classi.

    
risposta data 10.11.2010 - 17:40
fonte
1

Personalmente, sono contrario a questo tipo di commenti, ma solo perché la maggior parte degli editor di codice moderni ti consente di comprimere i metodi rendendoli più facili da leggere. L'aggiunta di commenti tende quindi a disordine poiché non contribuisce più a chiarire nulla, ma semplicemente a dichiarare il raggruppamento.

C # ha un raggruppamento che usa #region e #endregion che è utile. Eclipse fa un uso decente di un contorno.

Tuttavia, non esiste un modo sbagliato di commentare il codice e in generale non è "peggio" avere più commenti (non fingere di poter programmare più velocemente senza di esso).

    
risposta data 10.11.2010 - 16:25
fonte
1

Penso che andrebbe bene SE hai un sacco di codice che è simile, ad es. this.setProperty("prop", "val"); ancora e ancora. Quindi, potresti avere un metodo init () con una sezione di proprietà globali, proprietà locali e inizializzatori di sessione. Tuttavia, li inserirò ancora in metodi separati, a meno che non ci sia assolutamente alcuna possibilità che quel codice possa essere riutilizzato.

    
risposta data 10.11.2010 - 16:38
fonte
1

In un ambiente di scripting procedurale, in cui tutto il codice è contenuto in un file come subroutine, i commenti che descrivono sezioni di codice sarebbero indispensabili dopo un certo punto e non c'è niente di sbagliato in questo.

Attualmente sto fissando un Applescript lungo quasi 700 righe che sta per raddoppiare qui abbastanza presto (altri Applescripts ho oltre 2000 righe) con dozzine di subroutine. Spostare il codice su file esterni è più problematico di quanto valga la pena ora, quindi commentare le sezioni è il modo migliore di gestirlo tutto finché non trovo il tempo per migliorare la situazione.

Sto basando la mia risposta sul fatto che nella tua domanda hai usato specificamente la parola "script", che smentisce uno script procedurale rispetto al codice orientato agli oggetti.

    
risposta data 10.11.2010 - 16:22
fonte
0

Personalmente sarebbe ridondante. Il motivo è che se dovessi creare una funzione o una classe per gestire l'attività, allora dovrebbe essere una prefazione immediata per tornare indietro e apportare modifiche in futuro.

    
risposta data 10.11.2010 - 16:21
fonte

Leggi altre domande sui tag