2010-10-29 20 views
8

Sto cercando una risposta piuttosto arbitraria, quindi potrebbe essere più una discussione. Mi chiedo quale sia la migliore pratica per commentare il mio codice C# in Visual Studio. In questo momento sto usando il triplo /// per generare l'xml e usare sand castle per creare un file chm o html. Ma il mio problema è che io uso i commenti del codice per due motivi:commenting code C# visual studio best practice

  1. Quando gli altri sviluppatori stanno utilizzando il mio codice si può leggere la documentazione, sia Intellisence ed il chm. o file html.
  2. Ma io uso anche commenti come promemoria per me stesso. Quindi ricordo i miei pensieri quando tornerò dopo un anno e mezzo, con metodi complessi.

In che modo entrambi gli obiettivi possono essere raggiunti senza interferire tra loro e allo stesso tempo essere un compito rapido, senza impiegare molto tempo per la codifica?

risposta

15

Il miglior consiglio che posso darvi è:

Non commento codice cattivo; riscrivilo!

Se i metodi sono molto complessi, la maggior parte delle volte si sta facendo qualcosa di sbagliato (non sempre, ma molto vicino a sempre). Scrivere un codice leggibile è difficile, ma lo è, perché scrivere buoni commenti che tu (oi tuoi college) capirai un anno dopo è difficile (e forse anche più difficile). I modi per rendere le cose chiare sono suddividendo i metodi in metodi ben più piccoli e usando nomi di variabili molto chiari.

Un libro che mi ha aiutato molto a creare codice migliore è stato Robert Martins Clean Code. Se non l'hai letto, per favore fallo. E lascia che tutti gli sviluppatori della tua azienda lo leggano.

Buona fortuna.

+1

Grazie per la risposta. Penso che tutti abbiamo il problema del duello che ci viene pagato per il nostro lavoro, quindi dobbiamo creare un buon codice e non usare troppe ore per scriverlo. A volte i commenti possono essere usati come una soluzione rapida e sporca per questo. E so che non è la miglior pratica :) – DNRN

+0

Sono d'accordo con te. C'è sempre un compromesso tra buona qualità ed economia. Scrivo certamente commenti come "// TODO: non dimenticarti di refactoring" o "// HACK: fix later" personalmente :-) Ovviamente dipende dal tipo di progetto, ma spesso mi trovo a scrivere codice che ha essere mantenuto per molti anni (spesso da altre persone rispetto a me) e in tal caso paga davvero a lungo termine quando mi prendo molta cura di scriverlo. Quando scrivo un prototipo, prendo molto meno attenzione. – Steven

+1

@DNRN: parlando di economia, hai sentito parlare del concetto di "debito tecnico"?L'idea è che se rimanderai il refactoring per una data successiva, stai acquisendo un debito tecnico che dovrà essere ripagato in futuro, con interesse. L'interesse in questo caso è il sovraccarico di ricordare cosa fa il codice. Invece, raccomando uno strumento di refactoring di qualità, come ReSharper o CodeRush che rende il lavoro di refactoring estremamente efficiente. Usando uno strumento come questo, ottieni il meglio da entrambi i mondi ... refactor ora senza i tempi supplementari. –

6

Utilizzare i commenti /// per documentare l'API pubblica e protetta. Utilizza <remarks> per descrivere come deve essere utilizzata l'API. Il pubblico di questi commenti sono altri sviluppatori che usano il tuo codice.

Utilizzare i commenti // per commentare il proprio codice ogni volta che il codice da solo non è adeguato per comprendere appieno cosa sta succedendo. Il pubblico di questi commenti è te stesso forse tre mesi nel futuro o un altro sviluppatore intenzione di mantenere il tuo codice. Puoi usare commenti speciali come TODO o BUGBUG per contrassegnare i codici che devi rivedere.

+0

Io uso TODO me stesso come un piccolo promemoria di qualcosa che deve essere implementato in seguito, e l'ho trovato davvero utile. Mi piace la "vista dell'ottica" dove /// sono per API pubbliche e protette, utilizzate in intellisene. il utilizzato come informazioni aggiuntive nel file di documentazione. e // sono visualizzati solo in codice quando lo si rivede in un secondo momento. – DNRN

2

combino entrambi gli stili di commento - /// per la documentazione 'pubblico' su classi, metodi, ecc, e // sui commenti 'privati' per me o per i programmatori che mi seguono da leggere.

+0

Questo è quello che faccio pure io. – Mizipzor