.Documentation items
.Formatting/Referencing
The first category contains tags like <summary>, <param> or <exception>. These represent items
that represent the elements of a program's API which must be documented for the program to be useful to other programmers. These tags usually have attributes such as name or cref as demonstrated in the
multiline example above. These attributes are checked by the compiler, so they should be valid.
The latter category governs the layout of the documentation, using tags such as <code>, <list> or
<para>.
Documentation can then be generated using the 'documentation' item in the #develop 'build' menu. The
documentation generated is in HTMLHelp format.
For a fuller explanation of XML comments see the Microsoft .net framework SDK documentation. For
information on commenting best practice and further issues related to commenting, see the TechNote 'The
fine Art of Commenting'.

解决方案 »

  1.   

    在.net帮助中就有。
    你去看一下,挺全的。
    具体链接我不记得了,现在手头没环境。
      

  2.   

    我这里有一份中文的编码规范,你想要的话留下email。
      

  3.   

    sarmoo(Echo):
    能不能也发一份给我。
    [email protected]谢谢。
      

  4.   

    Software documentation exists in two forms, external and internal. External documentation is maintained outside of the source code, such as specifications, help files, and design documents. Internal documentation is composed of comments that developers write within the source code at development time. 
    One of the challenges of software documentation is ensuring that the comments are maintained and updated in parallel with the source code. Although properly commenting source code serves no purpose at run time, it is invaluable to a developer who must maintain a particularly intricate or cumbersome piece of software. 
    Following are recommended commenting techniques: 
    · When modifying code, always keep the commenting around it up to date. 
    · At the beginning of every routine, it is helpful to provide standard, boilerplate comments, indicating the routine's purpose, assumptions, and limitations. A boilerplate comment should be a brief introduction to understand why the routine exists and what it can do. 
    · Avoid adding comments at the end of a line of code; end-line comments make code more difficult to read. However, end-line comments are appropriate when annotating variable declarations. In this case, align all end-line comments at a common tab stop. 
    · Avoid using clutter comments, such as an entire line of asterisks. Instead, use white space to separate comments from code. 
    · Avoid surrounding a block comment with a typographical frame. It may look attractive, but it is difficult to maintain. 
    · Prior to deployment, remove all temporary or extraneous comments to avoid confusion during future maintenance work. 
    · If you need comments to explain a complex section of code, examine the code to determine if you should rewrite it. If at all possible, do not document bad code—rewrite it. Although performance should not typically be sacrificed to make the code simpler for human consumption, a balance must be maintained between performance and maintainability. 
    · Use complete sentences when writing comments. Comments should clarify the code, not add ambiguity. 
    · Comment as you code, because most likely there won't be time to do it later. Also, should you get a chance to revisit code you've written, that which is obvious today probably won't be obvious six weeks from now. 
    · Avoid the use of superfluous or inappropriate comments, such as humorous sidebar res. 
    · Use comments to explain the intent of the code. They should not serve as inline translations of the code. 
    · Comment anything that is not readily obvious in the code. 
    · To prevent recurring problems, always use comments on bug fixes and work-around code, especially in a team environment. 
    · Use comments on code that consists of loops and logic branches. These are key areas that will assist the reader when reading source code. 
    · Separate comments from comment delimiters with white space. Doing so will make comments stand out and easier to locate when viewed without color clues. 
    Throughout the application, construct comments using a uniform style, with consistent punctuation and structure.
      

  5.   

    我也要:[email protected] 谢谢了