2010-10-29 14 views
8

Estoy buscando una respuesta bastante arbitraria, por lo que esto podría ser más una discusión. Me pregunto cuál es la mejor práctica para comentar mi código C# en Visual Studio. En este momento estoy usando el triple /// para generar el xml y uso el castillo de arena para construir un archivo chm o html. Pero mi problema es que utilizo comentarios de código por dos razones:código de comentario C# visual studio mejor práctica

  1. Cuando otros desarrolladores usan mi código, pueden leer la documentación, tanto intellisence como chm. o archivo html
  2. Pero también uso comentarios como recordatorios para mí. Así que puedo recordar mis pensamientos cuando vuelvo medio año después, a algunos métodos complejos.

¿Cómo se pueden lograr ambos objetivos sin interferir entre sí, y al mismo tiempo ser una tarea rápida, sin tomar demasiado tiempo de codificación?

Respuesta

15

El mejor consejo que puedo dar es:

No haga comentarios código malo; reescríbelo!

Si los métodos son muy complejos, la mayoría de las veces está haciendo algo mal (no siempre, pero muy cerca de siempre). Escribir un código legible es difícil, pero vale la pena, porque escribir buenos comentarios que usted (o sus universidades) comprenda un año después también es difícil (y tal vez incluso más difícil). La forma de aclarar las cosas es dividir los métodos en métodos pequeños y bien nombrados y usar nombres de variables muy claros.

Un libro que me ha ayudado mucho a crear un mejor código fue Robert Martins Clean Code. Si no lo has leído, hazlo. Y permita que todos los desarrolladores de su empresa lo lean.

Buena suerte.

+1

Gracias por la respuesta. Creo que todos tenemos el problema del duelo porque nos pagan por nuestro trabajo, así que tenemos que crear un buen código y no utilizar demasiadas horas para escribirlo. A veces, los comentarios pueden usarse como una solución rápida y sucia para esto. Y sé que esto no es una buena práctica :) – DNRN

+0

Estoy de acuerdo contigo. Siempre hay una compensación entre la buena calidad y la economía. Ciertamente escribo comentarios como "// TODO: No olvides refactorizar esto" o "// HACK: arreglar más tarde" yo mismo :-) Por supuesto depende del tipo de proyecto, pero a menudo me encuentro escribiendo código que tiene para mantener durante muchos años (a menudo por otras personas que yo) y en ese caso, realmente vale la pena a largo plazo cuando me preocupo por escribirlo. Cuando escribo un prototipo me tomo mucho menos cuidado, por supuesto. – Steven

+1

@DNRN: Hablando de economía, ¿has oído hablar del concepto de "deuda técnica"?La idea es que si pospone la refactorización para una fecha posterior, en realidad está adquiriendo deuda técnica que tendrá que pagarse en el futuro, con interés. El interés en este caso es la sobrecarga de recordar lo que hace el código. En su lugar, recomiendo una herramienta de refactorización de calidad, como ReSharper o CodeRush, que hace que el trabajo de refactorización sea extremadamente eficiente. Usando una herramienta como esa, obtienes lo mejor de ambos mundos ... refactor ahora sin el tiempo extra. –

6

Use /// comentarios para documentar su API pública y protegida. Use <remarks> para describir cómo debería usarse su API. La audiencia de estos comentarios son otros desarrolladores que usan tu código.

Use // comentarios para comentar su código cada vez que el código solo no sea adecuado para comprender completamente lo que está sucediendo. El público de estos comentarios es usted quizás tres meses en el futuro o otro desarrollador va a mantener su código. Puede usar comentarios especiales como TODO o BUGBUG para marcar códigos que debe volver a visitar.

+0

Utilizo TODO como un pequeño recordatorio de algo que debe implementarse más tarde, y lo he encontrado realmente útil. Me gusta la "vista de alcance" donde /// son para API pública y protegida, utilizada en intellisene. el utilizado como información adicional en el archivo de documentación. y // solo se ven en el código cuando se revisa en otro momento. – DNRN

2

Combino ambos estilos de comentarios - /// para documentación 'pública' sobre clases, métodos, etc., y // sobre comentarios 'privados' para mí o para los programadores que me siguen para leer.

+0

Esto es lo que hago también. – Mizipzor

Cuestiones relacionadas