Commenti C # sulla chiusura {}

StackOverflow https://stackoverflow.com/questions/323837

  •  11-07-2019
  •  | 
  •  

Domanda

Ho lavorato un po 'con DevExpress CodeRush e Refactor! Pro questa settimana e ho raccolto un plug-in di commentatore che genererà automaticamente commenti durante la digitazione del codice.

Non voglio approfondire quanto sia bravo un lavoro nel scegliere il significato di base (abbastanza buono, in realtà) ma la sua implementazione predefinita solleva una domanda.

Per impostazione predefinita, digitando un carattere} per chiudere un blocco, il plugin aggiungerà un commento come il seguente ... 

using(MyType myType = new MyType())
{
    myType.doWork();
} // using

(vale a dire l'aggiunta di un commento all'etichetta della parentesi graffa di chiusura in cui è stata aperta.)

Mentre posso vedere che ci sono casi in cui questo comportamento può essere di grande utilità, sento che il codice risultante sembra molto disordinato con tutti i commenti aggiuntivi.

Mi stavo chiedendo che cosa ne pensassero gli altri, questo tipo di commento era. Non solo dal punto di vista accademico, ma se ricevo un buon numero di commenti negativi su di loro, posso decidere se infliggerli ai miei colleghi o eliminarli.

È stato utile?

Soluzione

Penso che commenti del genere siano inutili, a meno che ovviamente il codice non sia terribile. Con una corretta formattazione del codice non è difficile vedere dove inizia un blocco e dove termina un blocco perché di solito questi blocchi sono rientrati.

Modifica: Se una procedura è così grande che non è facilmente evidente quale blocco di codice viene chiuso da una parentesi graffa, allora dovrebbero esserci già più commenti descrittivi che descrivono comunque la procedura e questi commenti sarebbero solo disordinati.

Altri suggerimenti

Trovo piuttosto inutile l'idea di un plugin che genera commenti da codice. Se può essere dedotto dalla macchina, può anche essere dedotto da chiunque lo legga. È molto probabile che i commenti siano totalmente ridondanti.

Sento che quei commenti di parentesi graffe di chiusura sono disordinati, forniscono informazioni che sono meglio fornite direttamente dall'IDE se l'individuo lo desidera.

Non è necessario ogni commento IMO che descriva ciò che il codice ti sta già dicendo.

Se hai davvero blocchi di codice così lunghi che devi scorrere molto per vedere lì all'inizio hai fatto qualcosa di sbagliato e potresti considerare di dividere il codice.

Stile di commenti non corretti: introduce un overhead di mantenimento nella base di codice.

Ho conosciuto ex programmatori VB che hanno trovato confuse tracce di } nel codice di sintassi C, ma in questo scenario la vera soluzione è quella di riformattare il codice per impedire l'annidamento profondo e funzioni e / o blocchi di codice eccessivamente lunghi.

Forse utile se il blocco using si estende su una pagina nell'IDE, ma hai altri problemi di cui preoccuparti. In questo caso ci riesco con il rientro corretto e un IDE che evidenzia la parentesi graffa corrispondente quando ne seleziono una.

In generale, ho un pollice in giù, ma con un potenziale utilizzo quando non puoi evitare un blocco lungo altrimenti.

A volte otterrai blocchi di codice molto grandi o molti blocchi nidificati che si chiudono insieme. A volte uso questo stile in casi come questo, ma sicuramente non sempre. Nemmeno io mi limito al codice: l'HTML può trarre grandi vantaggi da questo stile di " commenti ravvicinati " ;: 

<div id="content">
    <div id="columns">
        <div class="column">

            <!-- .. snip a lot of lines .. -->

        </div> <!-- .column -->
    </div> <!-- #columns -->
</div> <!-- #content -->

Questo tipo di commenti è utile solo su blocchi di codice molto lunghi in cui sono presenti molti blocchi nidificati. Detto questo, tuttavia, non dovrebbe essere il caso in primo luogo poiché molti blocchi nidificati e metodi lunghi richiedono il refactoring. Quindi non mi piace affatto, visto che il lettore può ovviamente vedere quale blocco di codice sia.

Penso che più utile dei commenti sarebbe una funzione IDE per evidenziare non solo le coppie di parentesi graffe corrispondenti, ma anche visualizzare la linea di apertura su una descrizione comandi, in modo che se passassi sopra la parentesi graffa di chiusura nel tuo esempio, verrebbe fuori " using (MyType myType = new MyType ()) " in una descrizione comandi.

Ciò ti consentirebbe di dare facilmente un senso a parentesi graffe nidificate complesse per funzioni di grandi dimensioni senza fornire disordine visivo costante.

Trovo sempre utile ricordare questo ...

Un codice chiaro e ben scritto fornirà una spiegazione sufficiente di cosa sta facendo il codice affinché un programmatore competente lo raccolga.

I commenti devono essere lasciati nel codice per spiegare perché il codice lo sta facendo!

In altre parole, usa i commenti per aiutare il lettore del tuo codice a capire l'algoritmo, o cosa il codice dovrebbe raggiungere , non come lo sta raggiungendo!

Potresti voler dare un'occhiata a questo post di Jeff Atwood .

Non farlo, aggiunge semplicemente rumore se usato dappertutto, e oltre al rientro corretto dovrebbe risolvere il problema di leggibilità.

Lo terrei spento. Vedo un punto nell'uso di questo quando hai più blocchi che finiscono nello stesso posto (blocchi più lunghi o più corti) - li ho usati io stesso in alcuni casi come questi. Tuttavia, se vengono utilizzati, sarebbe meglio aggiungerli manualmente, in luoghi accuratamente selezionati piuttosto che avere uno strumento automatico che li aggiunge.

Se devi considerare se un certo tipo di commento è utilizzabile o meno, è molto probabile che sia quest'ultimo.

I commenti servono per spiegare alcuni blocchi di codice o un'entità nel suo insieme, per facilitare la comprensione; non per facilitare la lettura della formattazione.

Avere un plugin sempre conforme a questo comportamento è sia obeso che brutto.

Sono d'accordo che ci sono modi molto migliori per descrivere cosa sta facendo un codice.

Se hai un lungo corpus di codice preceduto da un singolo commento informativo come // Correggi oggetto di lavoro, potresti prendere quel codice e riformattarlo come suo metodo. Quindi utilizzare il commento come nome del nuovo metodo, FixWorkItem (). In questo modo è un modo rapido per rendere il tuo codice più autocompattante e potrebbe anche rivelare alcune caratteristiche di design che non hai notato prima.

Tieni d'occhio i commenti di una sola riga come potenziali refattori, che possono essere gestiti automaticamente dall'IDE. Il codice che documenta se stesso è migliore anche dei commenti autonomi meglio scritti, tranne ovviamente nel descrivere l'intento.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top