2010-05-31 10 views
42

quali token trovi utile in visual studio? (Visual Studio 2010ambientenell'elenco delle attività → gettoni)token nello studio visivo: HACK, TODO ... nessun altro?

Attualmente ho solo:

  • HACK-bassa
  • REVIEW - alta
  • TODO - normale
  • WTF - alta

(solo queste - eliminati alcuni tra quelli di default)

stai usando tutti gli altri?

stai coprendo qualsiasi altra cosa importante con i token di commento?

eventuali best practice? thnx

+0

dovrebbe probabilmente essere comunità wiki. – Konerak

+7

per chi atterra qui cercando i token elenco attività in Visual Studio, notare che i comandi del menu sono visual studio → strumenti → opzioni → ambiente → elenco attività → token – lib

risposta

25

Ecco quelli che uso:

  • TODO: la funzionalità non è ancora implementata
  • FIXME: il codice dovrebbe essere modificato/riscritta per raggiungere un certo obiettivo (manutenibilità elevata, le migliori prestazioni , e così via)
  • eRRORE: il codice ha un bug noto
+0

mi piace fixme e bug :) io uso hack per fixme. aggiungerà bug! – b0x0rz

+2

Io uso lo stesso :) - Faccio sottocataloghi per i miei FIXME, cioè FIXME - Performance. – cwap

+0

Sì. E TODO - TRANSLATE. Usiamo Mantis # 123 per fare riferimento al nostro sistema di bugtracking e al numero corrispondente. – Konerak

7

Un altro built-in è NOTA.

+4

sì, non mi è piaciuto visto che non c'è alcun commento a NOTA in qualche modo? – b0x0rz

+0

D'accordo, ma cerco di non usare i commenti affatto tranne NOTA. Se ho qualcos'altro, va nel sistema di tracciamento. Nel mio caso JIRA. –

+0

ah, capisco, io uso un po 'di più i commenti: P – b0x0rz

4

Vim evidenzia automaticamente XXX, che risulta essere il mio token di scelta per la facilità di digitazione.

Sun's (old) Java coding conventions hanno questo da dire:

Usa XXX in un commento per segnalare qualcosa che è fasullo, ma funziona. Utilizzare FIXME per contrassegnare qualcosa che è falso e rotto.

+1

bel consiglio su vim. non lo sapevo. – b0x0rz

21

Ho eseguito una combinazione della maggior parte dei token di cui sopra.

RED: code that simply does not work/compile 
// Error - This code is throwing a specific reproducible error. 
// Broken - This code is broken and will not run. 
// WTF - WHAT THE FRIG. 

ORANGE: code that works but is not right 
// Hack - This code has intentionally been hacked in order to work. Should not go into production. 
// FixMe - This code works but could be better. Needs better abstraction, maintainability, performance, etc. 
// Bug - This code works and was expected to be right but a bug has been found. (usually flagged post production) 
// Review - This code is probably right but should be reviewed for piece of mind. 
// Smells - Same as FixMe 

BLUE: code that works but either needs more features or more explaining 
// Todo - Functionality is not yet implemented 
// Note - Better explain what's going on. This is gives a higher profile to standard comments, and allows notes to be found in the to-do pane. 
+0

Io non uso necessariamente TUTTI questi, ma a seconda del mio umore quel giorno, otterrò i punti salienti in un modo o nell'altro. –

+0

È una cosa interessante se tutti i dipendenti della tua azienda hanno gli stessi token evidenziati. Se non lo fa, in alcuni casi rende i commenti più difficili da capire. –

+0

Come funziona _functionality non ancora implementato_ che funziona? –

6

Mi piace il Token RIMUOVERE, a indicare che è solo per un controllo, e non dovrebbero essere inclusi nella versione finale

+4

Questa è una pratica estremamente negativa. Se il codice è per il test, quindi utilizzare la compilazione condizionale con le direttive del preprocessore. – AMissico

+0

@AMissico ma '// REMOVE' è più facile – Gabriel

Problemi correlati