zoukankan      html  css  js  c++  java
  • c#书写规范之注释

     

    注释

    软件文档以两种形式存在:外部的和内部的。外部文档(如规范、帮助文件和设计文档)在源代码的外部维护。内部文档由开发人员在开发时在源代码中编写的注释组成。

    不考虑外部文档的可用性,由于硬拷贝文档可能会放错地方,源代码清单应该能够独立存在。外部文档应该由规范、设计文档、更改请求、错误历史记录和使用的编码标准组成。

    内部软件文档的一个难题是确保注释的维护与更新与源代码同时进行。尽管正确注释源代码在运行时没有任何用途,但这对于必须维护特别复杂或麻烦的软件片段的开发人员来说却是无价的。

    以下几点是推荐的注释方法:

    • 如果用 C# 进行开发,请使用 XML 文档格式,如下面方法的注释:

    /// <summary>

             /// 得到某人的年龄

             /// </summary>

             /// <param name="userName">用户名</param>

             /// <returns>用户年龄</returns>

             public int GetUserAge(string userName)

             {

                  //

                  //此处写你的程序代码

                  //

         }

    • 修改代码时,总是使代码周围的注释保持最新。
    • 在每个例程的开始,提供标准的注释样本以指示例程的用途、假设和限制很有帮助。注释样本应该是解释它为什么存在和可以做什么的简短介绍。
    • 避免在代码行的末尾添加注释;行尾注释使代码更难阅读。不过在批注变量声明时,行尾注释是合适的;在这种情况下,将所有行尾注释在公共制表位处对齐。
    • 避免杂乱的注释,如一整行星号。而是应该使用空白将注释同代码分开。
    • 避免在块注释的周围加上印刷框。这样看起来可能很漂亮,但是难于维护。
    • 在部署之前,移除所有临时或无关的注释,以避免在日后的维护工作中产生混乱。
    • 如果需要用注释来解释复杂的代码节,请检查此代码以确定是否应该重写它。尽一切可能不注释难以理解的代码,而应该重写它。尽管一般不应该为了使代码更简单以便于人们使用而牺牲性能,但必须保持性能和可维护性之间的平衡。
    • 在编写注释时使用完整的句子。注释应该阐明代码,而不应该增加多义性。
    • 在编写代码时就注释,因为以后很可能没有时间这样做。另外,如果有机会复查已编写的代码,在今天看来很明显的东西六周以后或许就不明显了。
    • 避免多余的或不适当的注释,如幽默的不主要的备注。
    • 使用注释来解释代码的意图。它们不应作为代码的联机翻译。
    • 注释代码中不十分明显的任何内容。
    • 为了防止问题反复出现,对错误修复和解决方法代码总是使用注释,尤其是在团队环境中。
    • 对由循环和逻辑分支组成的代码使用注释。这些是帮助源代码读者的主要方面。
    • 在整个应用程序中,使用具有一致的标点和结构的统一样式来构造注释。
    • 用空白将注释同注释分隔符分开。在没有颜色提示的情况下查看注释时,这样做会使注释很明显且容易被找到。
  • 相关阅读:
    聊聊WS-Federation
    用双十一的故事串起碎片的网络协议(上)
    责任链模式的使用-Netty ChannelPipeline和Mina IoFilterChain分析
    最小化局部边际的合并聚类算法(中篇)
    最小化局部边际的合并聚类算法(上篇)
    UVaLive 7371 Triangle (水题,判矩形)
    UVaLive 7372 Excellence (水题,贪心)
    POJ 3312 Mahershalalhashbaz, Nebuchadnezzar, and Billy Bob Benjamin Go to the Regionals (水题,贪心)
    UVa 1252 Twenty Questions (状压DP+记忆化搜索)
    UVa 10817 Headmaster's Headache (状压DP+记忆化搜索)
  • 原文地址:https://www.cnblogs.com/oec2003/p/737024.html
Copyright © 2011-2022 走看看