2010-05-31 9 views
42

¿qué tokens le parecen útiles en el estudio visual? (Visual Studio 2010ambientelista de tareas → fichas)tokens en visual studio: HACK, TODO ... ¿algún otro?

actualmente sólo tengo:

  • HACK - baja
  • REVIEW - alta
  • TODO - Normal
  • WTF - alta

(sólo estos borrados - algunos vienen por defecto)

¿Está utilizando alguna otra?

¿Estás cubriendo cualquier otra cosa importante con tokens de comentarios?

¿Alguna de las mejores prácticas? thnx

+0

probablemente debería ser wiki de la comunidad. – Konerak

+7

para quién aterriza aquí buscando los tokens de la lista de tareas en el estudio visual, tenga en cuenta que los comandos de menú son visual studio → herramientas → opciones → entorno → lista de tareas → tokens – lib

Respuesta

25

aquí está el que yo uso:

  • TODO: la funcionalidad aún no está implementado
  • ARREGLAME: el código debe ser modificado/refactorizado para alcanzar alguna meta (mayor facilidad de mantenimiento, un mejor rendimiento , y así sucesivamente)
  • eRROR: el código tiene un error conocido
+0

me gusta el fixme y el error :) uso hack para fixme. agregará error! – b0x0rz

+2

Uso el mismo :) - Hago subcategorías para mi FIXME, es decir: FIXME - Rendimiento. – cwap

+0

Sí. Y TODO - TRADUCIR. Usamos Mantis # 123 para referirnos a nuestro sistema de seguimiento de errores y el número correspondiente. – Konerak

7

Otro built-in es NOTA.

+4

sí, no me gustó ya que no hay ningún comentario a NOTA ¿de algun modo? – b0x0rz

+0

Estoy de acuerdo, pero trato de no utilizar ningún comentario excepto la NOTA. Si tengo algo más, entra en el sistema de seguimiento. En mi caso JIRA. –

+0

ah, ya veo, uso los comentarios un poco más: P – b0x0rz

4

Vim resalta automáticamente XXX, que es mi token de elección por la facilidad de escribirlo.

Sun's (old) Java coding conventions tiene esto que decir:

Uso XXX en un comentario a la bandera de algo que es falso, pero funciona. Use FIXME para marcar algo que es falso y está roto.

+1

buen consejo sobre vim. no lo sabía – b0x0rz

21

He hecho una combinación de la mayoría de los tokens anteriores.

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

No necesariamente uso TODO esto, pero dependiendo de mi estado de ánimo ese día, obtendré lo más destacado de una forma u otra. –

+0

Eso es algo genial si todos los empleados de su empresa tienen los mismos tokens destacados. Si no lo hace, solo hace que los comentarios sean más difíciles de entender en algunos casos. –

+0

¿Cómo aún no se ha implementado _functionality_ código que funciona? –

6

Me gusta el simbólico eliminar, lo que indica que es sólo en para las pruebas, y no deben ser incluidos en la versión final

+4

Esta es una práctica extremadamente mala. Si el código es para probar, entonces use la compilación condicional con las directivas del preprocesador. – AMissico

+0

@AMissico pero '// REMOVE' es más fácil – Gabriel

Cuestiones relacionadas