标签: 注释

6.3 函数注释  6.3.1 函数头部注释  函数头部注释应包括函数名称、函数功能、入口参数、出口参数等内容.如有必要还可增加作者、创建日期、修改记录(备注)等相关项目.  函数头部注释放在每个函数的顶端,用"/*……*/"的格式包含.其中函数名称应简写为FunctionName(),不加入、出口参数等信息.  /***********************************************************  函数名称:  函数功能:  入口参数:  出口参数:  备 注:  ***********************************************************/  6.3.2 代码注释  代码注释应与被注释的代码紧邻,放在其上方或右方,不可放在下面.如放于上方则需与其上面的代码用空行隔开.一般少量注释应该添加在被注释语句的行尾,一个函数内的多个注释左对齐;较多注释则应加在上方且注释行与被注释的语句左对齐.  函数代码注释用"//…//"的格式.  通常,分支语句(条件分支、循环语句等)必须编写注释.其程序块结束行"}"的右方应加表明该程序块结束的标记"end of ……", 尤其在多重嵌套时.  6.4 变量、常量、宏的注释  同一类型的标识符应集中定义,并在定义之前一行对其共性加以统一注释.对单个标识符的注释加在定义语句的行尾.  全局变量一定要有详细的注释,包括其功能、取值范围、哪些函数或过程存取它以及存取时的注意事项等.  注释用"//…//"的格式.  7 单片机C51编程规范-函数  7.1 设计原则  函数的基本要求:  l 正确性:程序要实现设计要求的功能.  l 稳定性和安全性:程序运行稳定、可靠、安全.  l 可测试性:程序便于测试和评价.  l 规范/可读性:程序书写风格、命名规则等符合规范.  l 扩展性:代码为下一次升级扩展留有空间和接口.  l 全局效率:软件系统的整体效率高.  l 局部效率:某个模块/子模块/函数的本身效率高.  编制函数的基本原则:  l 单个函数的规模尽量限制在200行以内(不包括注释和空行).一个函数只完成一个功能.  l 函数局部变量的数目一般不超过5~10个.  l 函数内部局部变量定义区和功能实现区(包含变量初始化)之间空一行.  l 函数名应准确描述函数的功能.通常使用动宾词组为执行某操作的函数命名.  l 函数的返回值要清楚明了,尤其是出错返回值的意义要准确无误.  l 不要把与函数返回值类型不同的变量,以编译系统默认的转换方式或强制的转换方式作为返回值返回.  l 减少函数本身或函数间的递归调用.  l 尽量不要将函数的参数作为工作变量.  7.2 函数定义  l 函数若没有入口参数或者出口参数,应用void明确申明.  l 函数名称与出口参数类型定义间应该空一格且只空一格.  l 函数名称与括号()之间无空格.  l 函数形参必须给出明确的类型定义.  l 多个形参的函数,后一个形参与前一个形参的逗号分割符之间添加一个空格.  l 函数体的前后花括号"{}" 各独占一行.  7.3 局部变量定义  l 同一行内不要定义过多变量.  l 同一类的变量在同一行内定义,或者在相邻行定义.  l 先定义data型变量,再定义idtata型变量,再定义xdata型变量.  l 数组、指针等复杂类型的定义放在定义区的最后.  l 变量定义区不做较复杂的变量赋值.  7.4 功能实现区规范  l 一行只写一条语句.  l 注意运算符的优先级,并用括号明确表达式的操作顺序,避免使用默认优先级.  l 各程序段之间使用一个空行分隔,加以必要的注释.程序段指能完一个较具体的功能的一行或多行代码.程序段内的各行代码之间相互依赖性较强.  l 不要使用难懂的技巧性很高的语句.  l 源程序中关系较为紧密的代码应尽可能相邻.  l 完成简单功能、关系非常密切的一条或几条语句可编写为函数或定义为宏.   

单片机C51编程规范  1单片机C51编程规范- 前言    为了提高源程序的质量和可维护性,从而最终提高软件产品生产力,特编写此规范.  2 单片机C51编程规范-范围    本标准规定了程序设计人员进行程序设计时必须遵循的规范.本规范主要针对C51编程语言和keil编译器而言,包括排版、注释、命名、变量使用、代码可测性、程序效率、质量保证等内容.  3 单片机C51编程规范-总则  l 格式清晰  l 注释简明扼要  l 命名规范易懂  l 函数模块化  l 程序易读易维护  l 功能准确实现  l 代码空间效率和时间效率高  l 适度的可扩展性  4 单片机C51编程规范-数据类型定义  编程时统一采用下述新类型名的方式定义数据类型.  建立一个datatype.h文件,在该文件中进行如下定义:  typedef bit BOOL; // 位变量 //  typedef unsigned char INT8U; // 无符号8位整型变量 //  typedef signed char INT8S; // 有符号8位整型变量 //  typedef unsigned int INT16U; // 无符号16位整型变量 //  typedef signed int INT16S; // 有符号16位整型变量 //  typedef unsigned long INT32U; // 无符号32位整型变量 //  typedef signed long INT32S; // 有符号32位整型变量 //  typedef float FP32; // 单精度浮点数(32位长度) //  typedef double FP64; // 双精度浮点数(64位长度) //  5 单片机C51编程规范-标识符命名  5.1 命名基本原则  l 命名要清晰明了,有明确含义,使用完整单词或约定俗成的缩写.通常,较短的单词可通过去掉元音字母形成缩写;较长的单词可取单词的头几个字母形成缩写.即"见名知意".  l 命名风格要自始至终保持一致.  l 命名中若使用特殊约定或缩写,要有注释说明.  l 除了编译开关/头文件等特殊应用,应避免使用以下划线开始和/或结尾的定义.  l 同一软件产品内模块之间接口部分的标识符名称之前加上模块标识.  5.2 宏和常量命名  宏和常量用全部大写字母来命名,词与词之间用下划线分隔.对程序中用到的数字均应用有意义的枚举或宏来代替.  5.3 变量命名  变量名用小写字母命名,每个词的第一个字母大写.类型前缀(u8\s8 etc.)全局变量另加前缀g_.  局部变量应简明扼要.局部循环体控制变量优先使用i、j、k等;局部长度变量优先使用len、num等;临时中间变量优先使用temp、tmp等.  5.4 函数命名  函数名用小写字母命名,每个词的第一个字母大写,并将模块标识加在最前面.  5.5 文件命名  一个文件包含一类功能或一个模块的所有函数,文件名称应清楚表明其功能或性质.  每个.c文件应该有一个同名的.h文件作为头文件.  6 单片机C51编程规范-注释  6.1 注释基本原则  l 有助于对程序的阅读理解,说明程序在"做什么",解释代码的目的、功能和采用的方法.  l 一般情况源程序有效注释量在30%左右.  l 注释语言必须准确、易懂、简洁.  l 边写代码边注释,修改代码同时修改相应的注释,不再有用的注释要删除.  6.2 文件注释  文件注释必须说明文件名、函数功能、创建人、创建日期、版本信息等相关信息.  修改文件代码时,应在文件注释中记录修改日期、修改人员,并简要说明此次修改的目的.所有修改记录必须保持完整.  文件注释放在文件顶端,用"/*……*/"格式包含.  注释文本每行缩进4个空格;每个注释文本分项名称应对齐.  /***********************************************************  文件名称:  作 者:  版 本:  说 明:  修改记录:  ***********************************************************/  6.3 函数注释  6.3.1 函数头部注释  函数头部注释应包括函数名称、函数功能、入口参数、出口参数等内容.如有必要还可增加作者、创建日期、修改记录(备注)等相关项目.  函数头部注释放在每个函数的顶端,用"/*……*/"的格式包含.其中函数名称应简写为FunctionName(),不加入、出口参数等信息.  /***********************************************************  函数名称:  函数功能:  入口参数:  出口参数:  备 注:  ***********************************************************/   

在软件开发过程中没有比获得一个只有很少甚至没有说明文档的代码库而又要求进行维护更具挑战性的事情了。这些文档不只是告诉工程师某个特定函数或变量是做什么的，而且能够展示和传达软件为何以某个特定方式实现。在软件实现过程中会作出成千上万个决策，因此维护工程师甚至未来的你尽可能多地保留这些决策过程至关重要。 注释代码的问题部分原因来自出货压力、不正确的设计以及注释代码是如何工作的事情没有开发来得有趣或兴奋这个事实！许多工程师(包括我自己)憎恨必须注释代码，但这项工作在嵌入式工程师开发过程中是如此重要，以致于我们绝对不能省略或三意二意地去做。然而，可以在软件开发过程中记住一些技巧，它们有助于确保未来开发人员维护好代码开发中的任何细微变动。 技巧1——随时而不是过后进行注释 交付产品的压力经常导致天马行空般的编码风格，为了完成任务以便尽早推出产品，代码是想到哪就编到哪。在疯狂的代码编写过程中，很少想到记录下代码要完成的功能。等产品交货后，设计人员才会回去浏览代码并进行“注释”。这样做的问题是，这时已经距离写完代码几周甚至几个月的时间了！对一些工程师来说记起昨天早餐吃的是什么都很难，更不用说两周前写的一段代码了。最终结果是不准确的注释说明，日后往往会引起误解和缺陷。 这里的技巧当然是在进行决策的同时随时进行注释。形式化的外部文档注释过程无疑会降低开发人员的进度，但向代码库中增加注释真的不会占用更多时间。开发人员能够做的第一件事是先对代码要做什么事写一些注释行，然后再写代码。如果实现发生了变化，开发人员可以立即更新注释。在任何情况下，在编写代码的同时写下注释只会节省时间和增加条理性，从而更少发生错误，产品也能更快的上市。 《电子技术设计》网站版权所有，谢绝转载 技巧2——自动生成注释文档 尽管对代码做了很详细的注释，但总是有生成外部文档的要求，以便任何人不看代码就能明白程序功能。这个要求经常导致双倍的注释工作量。幸运的是，市场上有现成的工具可以自动读取代码注释、然后生成界面和代码的其它文档细节！帮助工程师避免必须做两次相同的工作！一个具有这种功能的免费工具例子是Doxygen。当开发人员在编写他们的代码时，他们以指定方式格式化他们的注释，并提供他们想要在外部文档中展示的细节内容。然后他们就可以运行Doxygen生成真实反映软件内注释的html、rtf或pdf文档。美妙的是如果你更新注释，外部文档也会自动更新！有关如何获得这款工具并运行的教程可以在www.beningo.com网站的Design Articles-Design Cycle专栏中找到。 技巧3——不要写显式的注释 虽然开发人员写了代码注释，但如果注释只是变量或函数名字的重复，会特别令人恼火。注释应该是描述性的文字，需要提供显式意思之外更多的细节！提供尽可能多的信息，而且不要忘了提及相关和关联的变量或函数。开发人员应该能够只通过阅读注释就了解软件的行为。图1给出了一个注释简单映射数组代码的例子。 图1：映射数组。 《电子技术设计》网站版权所有，谢绝转载 技巧4——提供使用例子以便更清楚地了解用途 函数或变量注释中包含如何使用它们的例子是很有用的。说应该如何使用是一回事，但展示如何使用会让人更清楚其用途。除了能够减少错误使用对象的机会外，还能给人一个更清晰的印象。图2显示了一个如何注释函数的例子，它告诉开发人员应该如何使用这个函数，从而避免了容易出错的猜测过程，使人能够更清晰地了解其用途。 图2——使用例子。 技巧5——创建注释标准 就像写代码一样，为代码开发注释和文档也应该有个标准。由于注释标准中不可能有许多条款，因此特别推荐向编写代码标准靠拢。也就是说确保小组中的每个成员以相同的方式进行注释和归档，从而确保开发的易用性。开发人员应该专注于解决手头的设计问题，而不是费劲地去搞懂注释。 《电子技术设计》网站版权所有，谢绝转载 技巧6——使用文档模板 确保注释遵循标准的最容易的方法是为头文件、源文件和支持文件创建模板。当创建一个新模块时，可以从模板入手，然后增加相关的信息。这将有助于确保文件信息块、代码段、函数和变量都用相同的格式注释。这种方法的最大优势是能够节省大量时间，并有助于减少将一个模块拷贝到另一个伪模板时发生的拷贝粘贴错误。为了让生活更加轻松，我特意开发了可以用于定义头文件和源文件的模板。 技巧7——图表的作用 在一个项目的软件实现阶段开始之前，应该有一个软件设计阶段。这个设计阶段无疑会生成许多漂亮的图(如流程图和状态机)，并被用于实际实现。虽然这些文档作为软件的开发路线图，但在开发和测试过程中总会出现偏差！遗憾的是，这些变化很少会返回到图表中。结果是设计文档和软件的不匹配！在实现和测试阶段将这些图表放在手边，以便发生上述偏差时这些图表能及时得到更新。将这些图表留到日后更新永远不是正确的做法。虽然我们总是有返回去更新或修复的良好愿望，但这永远不是合适的时机。 技巧8——保持注释框使用的一致性 就像听起来一样奇怪，许多网络争论的内容是何时、哪里使用何种类型的注释框！不过严肃地讲，不管你的信仰是什么，归根到底是一致性问题。如果一个团队决定只使用/*…*/类型的注释，那么就只使用这种类型。如果决定使用//类型，那就只使用//类型。作者个人的观点是倾向于使用/*…*/进行函数和模块级说明，使用//进行函数代码说明。不管选择是什么，确保每次都按同样的方式去做，这样有助于生活更加轻松。 《电子技术设计》网站版权所有，谢绝转载 技巧9——使注释更容易阅读(即格式的美化) 为了确保避免误解并由此产生代码缺陷，使代码保持结构化和容易阅读很重要。注释也一样。偶尔结构化的注释会使眼睛很难捕捉注释，更难捕捉不在合适位置的内容。应该对注释进行格式化处理，这样如果代码打印出来时(虽然现在不常打印，但我偶然仍会打印代码)注释就不会分到好几页上去。在大块注释(如文件头或函数注释)中，如果你使用块指示器，千万不要包含进任何拖尾字符(如#或*)，要不只会使文档更新变得更加困难。 技巧10——嵌入图像和图表 借助自动化工具的使用，在注释文档中包含编码标准、缩写词、项目细节、要求和大量其它条款就成了可能。甚至能够包含诸如流程图等设计性图表！使用这类功能允许代码库不仅包含执行代码和逻辑，还包含你想要了解的项目所有内容，并且所有信息都放在同一个地方。 作者：Jacob Beningo 《电子技术设计》网站版权所有，谢绝转载

在软件开发过程中没有比获得一个只有很少甚至没有说明文档的代码库而又要求进行维护更具挑战性的事情了。这些文档不只是告诉工程师某个特定函数或变量是做什么的，而且能够展示和传达软件为何以某个特定方式实现。在软件实现过程中会作出成千上万个决策，因此维护工程师甚至未来的你尽可能多地保留这些决策过程至关重要。 注释代码的问题部分原因来自出货压力、不正确的设计以及注释代码是如何工作的事情没有开发来得有趣或兴奋这个事实！许多工程师(包括我自己)憎恨必须注释代码，但这项工作在嵌入式工程师开发过程中是如此重要，以致于我们绝对不能省略或三意二意地去做。然而，可以在软件开发过程中记住一些技巧，它们有助于确保未来开发人员维护好代码开发中的任何细微变动。 技巧1——随时而不是过后进行注释 交付产品的压力经常导致天马行空般的编码风格，为了完成任务以便尽早推出产品，代码是想到哪就编到哪。在疯狂的代码编写过程中，很少想到记录下代码要完成的功能。等产品交货后，设计人员才会回去浏览代码并进行“注释”。这样做的问题是，这时已经距离写完代码几周甚至几个月的时间了！对一些工程师来说记起昨天早餐吃的是什么都很难，更不用说两周前写的一段代码了。最终结果是不准确的注释说明，日后往往会引起误解和缺陷。 这里的技巧当然是在进行决策的同时随时进行注释。形式化的外部文档注释过程无疑会降低开发人员的进度，但向代码库中增加注释真的不会占用更多时间。开发人员能够做的第一件事是先对代码要做什么事写一些注释行，然后再写代码。如果实现发生了变化，开发人员可以立即更新注释。在任何情况下，在编写代码的同时写下注释只会节省时间和增加条理性，从而更少发生错误，产品也能更快的上市。 《电子技术设计》网站版权所有，谢绝转载 技巧2——自动生成注释文档 尽管对代码做了很详细的注释，但总是有生成外部文档的要求，以便任何人不看代码就能明白程序功能。这个要求经常导致双倍的注释工作量。幸运的是，市场上有现成的工具可以自动读取代码注释、然后生成界面和代码的其它文档细节！帮助工程师避免必须做两次相同的工作！一个具有这种功能的免费工具例子是Doxygen。当开发人员在编写他们的代码时，他们以指定方式格式化他们的注释，并提供他们想要在外部文档中展示的细节内容。然后他们就可以运行Doxygen生成真实反映软件内注释的html、rtf或pdf文档。美妙的是如果你更新注释，外部文档也会自动更新！有关如何获得这款工具并运行的教程可以在www.beningo.com网站的Design Articles-Design Cycle专栏中找到。 技巧3——不要写显式的注释 虽然开发人员写了代码注释，但如果注释只是变量或函数名字的重复，会特别令人恼火。注释应该是描述性的文字，需要提供显式意思之外更多的细节！提供尽可能多的信息，而且不要忘了提及相关和关联的变量或函数。开发人员应该能够只通过阅读注释就了解软件的行为。图1给出了一个注释简单映射数组代码的例子。 图1：映射数组。 《电子技术设计》网站版权所有，谢绝转载 技巧4——提供使用例子以便更清楚地了解用途 函数或变量注释中包含如何使用它们的例子是很有用的。说应该如何使用是一回事，但展示如何使用会让人更清楚其用途。除了能够减少错误使用对象的机会外，还能给人一个更清晰的印象。图2显示了一个如何注释函数的例子，它告诉开发人员应该如何使用这个函数，从而避免了容易出错的猜测过程，使人能够更清晰地了解其用途。 图2——使用例子。 技巧5——创建注释标准 就像写代码一样，为代码开发注释和文档也应该有个标准。由于注释标准中不可能有许多条款，因此特别推荐向编写代码标准靠拢。也就是说确保小组中的每个成员以相同的方式进行注释和归档，从而确保开发的易用性。开发人员应该专注于解决手头的设计问题，而不是费劲地去搞懂注释。 《电子技术设计》网站版权所有，谢绝转载 技巧6——使用文档模板 确保注释遵循标准的最容易的方法是为头文件、源文件和支持文件创建模板。当创建一个新模块时，可以从模板入手，然后增加相关的信息。这将有助于确保文件信息块、代码段、函数和变量都用相同的格式注释。这种方法的最大优势是能够节省大量时间，并有助于减少将一个模块拷贝到另一个伪模板时发生的拷贝粘贴错误。为了让生活更加轻松，我特意开发了可以用于定义头文件和源文件的模板。 技巧7——图表的作用 在一个项目的软件实现阶段开始之前，应该有一个软件设计阶段。这个设计阶段无疑会生成许多漂亮的图(如流程图和状态机)，并被用于实际实现。虽然这些文档作为软件的开发路线图，但在开发和测试过程中总会出现偏差！遗憾的是，这些变化很少会返回到图表中。结果是设计文档和软件的不匹配！在实现和测试阶段将这些图表放在手边，以便发生上述偏差时这些图表能及时得到更新。将这些图表留到日后更新永远不是正确的做法。虽然我们总是有返回去更新或修复的良好愿望，但这永远不是合适的时机。 技巧8——保持注释框使用的一致性 就像听起来一样奇怪，许多网络争论的内容是何时、哪里使用何种类型的注释框！不过严肃地讲，不管你的信仰是什么，归根到底是一致性问题。如果一个团队决定只使用/*…*/类型的注释，那么就只使用这种类型。如果决定使用//类型，那就只使用//类型。作者个人的观点是倾向于使用/*…*/进行函数和模块级说明，使用//进行函数代码说明。不管选择是什么，确保每次都按同样的方式去做，这样有助于生活更加轻松。 《电子技术设计》网站版权所有，谢绝转载 技巧9——使注释更容易阅读(即格式的美化) 为了确保避免误解并由此产生代码缺陷，使代码保持结构化和容易阅读很重要。注释也一样。偶尔结构化的注释会使眼睛很难捕捉注释，更难捕捉不在合适位置的内容。应该对注释进行格式化处理，这样如果代码打印出来时(虽然现在不常打印，但我偶然仍会打印代码)注释就不会分到好几页上去。在大块注释(如文件头或函数注释)中，如果你使用块指示器，千万不要包含进任何拖尾字符(如#或*)，要不只会使文档更新变得更加困难。 技巧10——嵌入图像和图表 借助自动化工具的使用，在注释文档中包含编码标准、缩写词、项目细节、要求和大量其它条款就成了可能。甚至能够包含诸如流程图等设计性图表！使用这类功能允许代码库不仅包含执行代码和逻辑，还包含你想要了解的项目所有内容，并且所有信息都放在同一个地方。 作者：Jacob Beningo 《电子技术设计》网站版权所有，谢绝转载

在软件开发过程中没有比获得一个只有很少甚至没有说明文档的代码库而又要求进行维护更具挑战性的事情了。这些文档不只是告诉工程师某个特定函数或变量是做什么的，而且能够展示和传达软件为何以某个特定方式实现。在软件实现过程中会作出成千上万个决策，因此维护工程师甚至未来的你尽可能多地保留这些决策过程至关重要。 注释代码的问题部分原因来自出货压力、不正确的设计以及注释代码是如何工作的事情没有开发来得有趣或兴奋这个事实！许多工程师(包括我自己)憎恨必须注释代码，但这项工作在嵌入式工程师开发过程中是如此重要，以致于我们绝对不能省略或三意二意地去做。然而，可以在软件开发过程中记住一些技巧，它们有助于确保未来开发人员维护好代码开发中的任何细微变动。 技巧1——随时而不是过后进行注释 交付产品的压力经常导致天马行空般的编码风格，为了完成任务以便尽早推出产品，代码是想到哪就编到哪。在疯狂的代码编写过程中，很少想到记录下代码要完成的功能。等产品交货后，设计人员才会回去浏览代码并进行“注释”。这样做的问题是，这时已经距离写完代码几周甚至几个月的时间了！对一些工程师来说记起昨天早餐吃的是什么都很难，更不用说两周前写的一段代码了。最终结果是不准确的注释说明，日后往往会引起误解和缺陷。 这里的技巧当然是在进行决策的同时随时进行注释。形式化的外部文档注释过程无疑会降低开发人员的进度，但向代码库中增加注释真的不会占用更多时间。开发人员能够做的第一件事是先对代码要做什么事写一些注释行，然后再写代码。如果实现发生了变化，开发人员可以立即更新注释。在任何情况下，在编写代码的同时写下注释只会节省时间和增加条理性，从而更少发生错误，产品也能更快的上市。 《电子技术设计》网站版权所有，谢绝转载 技巧2——自动生成注释文档 尽管对代码做了很详细的注释，但总是有生成外部文档的要求，以便任何人不看代码就能明白程序功能。这个要求经常导致双倍的注释工作量。幸运的是，市场上有现成的工具可以自动读取代码注释、然后生成界面和代码的其它文档细节！帮助工程师避免必须做两次相同的工作！一个具有这种功能的免费工具例子是Doxygen。当开发人员在编写他们的代码时，他们以指定方式格式化他们的注释，并提供他们想要在外部文档中展示的细节内容。然后他们就可以运行Doxygen生成真实反映软件内注释的html、rtf或pdf文档。美妙的是如果你更新注释，外部文档也会自动更新！有关如何获得这款工具并运行的教程可以在www.beningo.com网站的Design Articles-Design Cycle专栏中找到。 技巧3——不要写显式的注释 虽然开发人员写了代码注释，但如果注释只是变量或函数名字的重复，会特别令人恼火。注释应该是描述性的文字，需要提供显式意思之外更多的细节！提供尽可能多的信息，而且不要忘了提及相关和关联的变量或函数。开发人员应该能够只通过阅读注释就了解软件的行为。图1给出了一个注释简单映射数组代码的例子。 图1：映射数组。 《电子技术设计》网站版权所有，谢绝转载 技巧4——提供使用例子以便更清楚地了解用途 函数或变量注释中包含如何使用它们的例子是很有用的。说应该如何使用是一回事，但展示如何使用会让人更清楚其用途。除了能够减少错误使用对象的机会外，还能给人一个更清晰的印象。图2显示了一个如何注释函数的例子，它告诉开发人员应该如何使用这个函数，从而避免了容易出错的猜测过程，使人能够更清晰地了解其用途。 图2——使用例子。 技巧5——创建注释标准 就像写代码一样，为代码开发注释和文档也应该有个标准。由于注释标准中不可能有许多条款，因此特别推荐向编写代码标准靠拢。也就是说确保小组中的每个成员以相同的方式进行注释和归档，从而确保开发的易用性。开发人员应该专注于解决手头的设计问题，而不是费劲地去搞懂注释。 《电子技术设计》网站版权所有，谢绝转载 技巧6——使用文档模板 确保注释遵循标准的最容易的方法是为头文件、源文件和支持文件创建模板。当创建一个新模块时，可以从模板入手，然后增加相关的信息。这将有助于确保文件信息块、代码段、函数和变量都用相同的格式注释。这种方法的最大优势是能够节省大量时间，并有助于减少将一个模块拷贝到另一个伪模板时发生的拷贝粘贴错误。为了让生活更加轻松，我特意开发了可以用于定义头文件和源文件的模板。 技巧7——图表的作用 在一个项目的软件实现阶段开始之前，应该有一个软件设计阶段。这个设计阶段无疑会生成许多漂亮的图(如流程图和状态机)，并被用于实际实现。虽然这些文档作为软件的开发路线图，但在开发和测试过程中总会出现偏差！遗憾的是，这些变化很少会返回到图表中。结果是设计文档和软件的不匹配！在实现和测试阶段将这些图表放在手边，以便发生上述偏差时这些图表能及时得到更新。将这些图表留到日后更新永远不是正确的做法。虽然我们总是有返回去更新或修复的良好愿望，但这永远不是合适的时机。 技巧8——保持注释框使用的一致性 就像听起来一样奇怪，许多网络争论的内容是何时、哪里使用何种类型的注释框！不过严肃地讲，不管你的信仰是什么，归根到底是一致性问题。如果一个团队决定只使用/*…*/类型的注释，那么就只使用这种类型。如果决定使用//类型，那就只使用//类型。作者个人的观点是倾向于使用/*…*/进行函数和模块级说明，使用//进行函数代码说明。不管选择是什么，确保每次都按同样的方式去做，这样有助于生活更加轻松。 《电子技术设计》网站版权所有，谢绝转载 技巧9——使注释更容易阅读(即格式的美化) 为了确保避免误解并由此产生代码缺陷，使代码保持结构化和容易阅读很重要。注释也一样。偶尔结构化的注释会使眼睛很难捕捉注释，更难捕捉不在合适位置的内容。应该对注释进行格式化处理，这样如果代码打印出来时(虽然现在不常打印，但我偶然仍会打印代码)注释就不会分到好几页上去。在大块注释(如文件头或函数注释)中，如果你使用块指示器，千万不要包含进任何拖尾字符(如#或*)，要不只会使文档更新变得更加困难。 技巧10——嵌入图像和图表 借助自动化工具的使用，在注释文档中包含编码标准、缩写词、项目细节、要求和大量其它条款就成了可能。甚至能够包含诸如流程图等设计性图表！使用这类功能允许代码库不仅包含执行代码和逻辑，还包含你想要了解的项目所有内容，并且所有信息都放在同一个地方。 作者：Jacob Beningo 《电子技术设计》网站版权所有，谢绝转载