C++注释规范 (1)
C++注释规范
前言
为了保持程序源码与文档的一致性，提出了源码注释规范化。文档修订记录
1适用范围
C++
2引用文件
doxygen_manual-1.5.9.pdf
3术语
4概述
根据文档化的源码，直接从源码中抽取文档，保持文档源码一致性。采用开源工具Doxygen，支持输出html、pdf、chm、man手册等。Doxygen支持两种形式的注释：JavaDoc 和QT风格，本规范采用通用的JavaDoc形式，更适合一般的编程习惯。
5Doxygen安装
5.1 Windows平台
?直接运行Doxygen 的Setup EXE文件，依据提示进行安装操作；
?运行Graphviz的安装（EXE）文件，依据提示进行安装操作。
6Doxygen运行
DOXYFILE_ENCODING=GBK
OUTPUT_LANGUAGE=Chinese
INPUT_ENCODING=GBK
FILE_PATTERNS=*.h *.cpp
RECURSIVE=true
EXTRACT_ALL=TRUE
EXTRACT_PRIVA TE=TRUE
EXTRACT_STATIC=TRUE
EXTRACT_LOCAL_CLASSES=TRUE
EXTRACT_LOCAL_METHODS=TRUE
SHOW_INCLUDE_FILES=TRUE
INLINE_INFO=TRUE
SHOW_DIRECTORIES=TRUE
SHOW_FILES=TRUE
SHOW_NAMESPACE=TRUE
7Doxygen介绍
如果采用Doxygen为代码产生文档，在编写代码时首先要为代码添加Doxygen风格的注释，这些Doxygen风格的注释可以称为文档块(Document block)，添加注释的这个动作可以称为文档化代码。Doxygen会根据相应的doxygen注释块为代码生成相应的文档。
对每个代码条目，Doxygen有两种（在某些情况下可以3种）类型的说明，共同组成文档：简要说明和详细说明。对应方法和函数可以有第三种风格的注释，函数体内注释（in body）。因为没有指定描述顺序，因此不建议多条简要说明或详细说明。
简要说明只有一行，详细说明可以有多行。
以下描述全部以JavaDoc为例。
7.1 详细注释
1、JavaDoc风格的注释，这种风格的注释是在C风格的注释块开始处有两个“* “，如下：
/**
* ... 注释块...
*/
上例中文本前的“* “是可选的，也可以写成
/**
... 注释块...
*/
3、单行注释也可以采用如下方式
///
/// ... 注释...
///
4、如下注释也是可以的
/********************************************//**
* ... 注释
***********************************************/
或者
/////////////////////////////////////////////////
/// ...注释...
/////////////////////////////////////////////////
7.2 简要注释
如果配置文件中把JA V ADOC_AUTOBRIEF 设置成YES，则可以使用JavaDoc风格注释块, 这种风格的注释，简要说明自动从“*“后开始，直到第一个”.”号结束，例如：
/** 简要说明.
* 详细说明.
*/
多行C++风格注释：
/// 简要说明.
/// 详细说明.
3、可以采用如下注释：
/// 简要说明.
/** 详细说明. */
上例中间空行用来分隔简要说明和详细说明的。请注意下面格式的注释是不合法的，Doxygen只允许一条详细说明对应一条简要说明：
如果一个代码项的声明和定义之前都有简要说明，则Doxygen只使用声明之前的说明。
如果一个代码项在声明和定义之前都有详细说明, 则Doxygen使用定义之前的说明。
7.3 模块注释
7.3.1定义模块（组）
/*
* @defgroup 模块名（具有唯一性）模块的说明文字
* @{
*/
…定义的内容…
/** @} */ // 模块结尾
7.3.2增加到组中
在文档块中增加:ingroup 模块名
7.3.3示例
/** @defgroup common common lib
* This is the first group
* @{
* @}
*/
/** @defgroup base base lib
* @ingroup common
*/
7.4 成员分组
如果一个组合结构（如类、文件）有很多成员，则可能需要对这些成员进行分组。Doxygen 会根据类型和保护方式自动进行分组。成员分组不能嵌套。
/*
* @name 分组说明文字
* @{
*/
…定义的内容…
/** @} */
7.5 Subpaging（子页面）暂无用
增加的页面与主页面（main page）在同一层次，当然主页面在最前。使用命令page、mainpage 定义页面，然后使用命令subpage增加页面。
/** @mainpage A simple manual
* Some general info.
* This manual is divided in the following sections:
* @subpage intro
* @subpage advanced "Advanced usage"
*/
/** @page intro Introduction
* This page introduces the user to the topic.
* Now you can proceed to the \ref advanced "advanced section".
*/
/** @page advanced Advanced Usage
* This page is for advanced users.
* Make sure you have first read \ref intro "the introduction".
*/
7.6 文件注释
/**
* @file 1.cpp
* @author lijiansheng
* @version 0.1
* @date 2009
* @defgroup testgroup test
* @ingroup base
* @brief 日期处理类.
* @details对日期包装的处理
*
* @history
*/
为了让文件信息出现在“模块”页面，需要将该文件定义为一个模块或组。
7.7 类注释
/**
* @class CTest
* @ingroup testgroup
* @brief test class
*
* @details test details class
*/
class CTest{
};
7.8 函数注释
/**
* a normal member taking two arguments and returning an integer value. * @param[in] a an integer argument.
* @param[out] s a constant character pointer.
* @see testMe2()
* @return The test results
*/
7.9 变量注释
有三种形式，示例如下：
7.9.1示例一
/**
* test var
*/
double m_dTest;
7.9.2示例二
double m_dTest; ///< test var
7.9.3示例三
double m_dTest; /**< test var */
7.10 C遗留结构（define、union、struct、enum）参考变量注释
7.11 常用命令：
struct 文档化C结构体
union 文档化联合类型
enum 文档化枚举类型
fn 文档化函数
var 文档化变量、typedef或枚举类型
def 文档化#define定义
typedef 文档化typedef定义
file 文档化文件
namespace 文档化命名空间
package 文档化Java包
interface 文档化接口
8规范
代码文档化，尤其对于公共库、业务库是必不可少了，可以编程效率。
8.1 文件注释规范
需要将文件归属到某个组
/**
* @file 1.cpp
* @author lijiansheng
* @version 0.1
* @date 2009
* @defgroup testgroup test
* @ingroup base
* @brief 日期处理类.
* @details对日期包装的处理
*
* @history
*/
8.2 类注释规范
需要将类归属到某个组
/**
* @class CTest
* @ingroup testgroup
* @brief test class
*
* @details test details class
*/
class CTest{
};
8.3 函数注释规范
/**
* a normal member taking two arguments and returning an integer value. * @param[in] a an integer argument.
* @param[out] s a constant character pointer.
* @see testMe2()
* @return The test results
*/
8.4 变量注释及遗留结构注释规范
注释有三种形式，示例如下：
8.4.1示例一
/**
* test var
*/
double m_dTest;
8.4.2示例二
double m_dTest; ///< test var 8.4.3示例三
double m_dTest; /**< test var */
C语言注释规范
C语言注释规范 1.注释原则 同一软件项目开发中，尽量保持代码注释规范和统一。 注释方便了代码的阅读和维护。 边写代码边注释，修改代码时要相应修改注释，保证注释和代码的一致性。 注释要简洁明确，不要出现形容词。 对于写的好的注释，我们将是第一个受益者。 大型软件开发中，通过别人的注释可以快速知道他人所写函数的功能，返回值，参数的使用。 2.文件头部的注释 示例： / * Program Assignment : 该文件的作用 * Author: 作者 * Date: 2013/8/6 14:34 * Description: 该文件的描述 *****/ /* * Source code in : 源代码的路径 * Function List: * initLinear 初始化线性表 * destoryLinear 释放线性表申请的空间 * isLinearEmpty 判断线性表是否为空 * isLinearFull 判断线性表是否为满 * getLinearElementValue 取得下标为index的元素的值 */ 注意：这个函数列表可以快速查询到我们想要了解的函数。 3.结构体，全局变量等的注释 示例： typedef POLYNOMIAL USER_TYPE; /* 新的数据类型的描述*/ int a; /* 全局变量的作用*/ /* 说明结构体的功能*/ typedef struct LINEAR { USER_TYPE *data; /* 每个成员的意义(作用) */ int maxRoom; /* 每个成员的意义(作用) */
int elementCount; /* 每个成员的意义(作用) */ }LINEAR; 4.函数的注释 在逻辑性较强的的地方加入注释，以便其他人的理解，在一定的程度上排除bug。 示例： /* * Function Name: getLinearElementIndex * Purpose: 取得元素的index值 * Params : * @LINEAR linear 线性表实例 * @USER_TYPE var 类型为USER_TYPE的实例 * @int (*)() cmp 提供接口，让用户定义具体比较函数 * Return: int 返回元素的index值 * Limitation: 如果返回-1，则代表不存在var的元素 */ int getLinearElementIndex(LINEAR linear, USER_TYPE var, int (*cmp)()) { /* * 如果逻辑太过复杂，这里写明该算法的过程和思路。 */ boolean found = FALSE; int i; for(i = 0; i < && !found; i++) if(cmp[i], var) == 0) found = TRUE; if(i >= i = NOT_FOUND; return i; }
MyEclipse设置Java代码注释模板
设置注释模板的入口：Window->Preference->Java->Code Style->Code Template 然后展开Comments节点就是所有需设置注释的元素啦。现就每一个元素逐一介绍： 文件(Files)注释标签： /** * @Title: ${file_name} * @Package ${package_name} * @Description: ${todo} * @author chenguang * @date ${date} ${time} * @version V1.0 */ 类型(Types)注释标签（类的注释）： /** * 类功能说明 * 类修改者修改日期 * 修改说明 * Title: ${file_name} * Description:清大海辉科技开发平台 * Copyright: Copyright (c) 2006 * Company:北京清大海辉科技有限公司 * @author ${user} * @date ${date} ${time} * @version V1.0 */ 字段(Fields)注释标签： /** * @Fields ${field} : ${todo} */ 构造函数标签： /** * Title: * Description: * ${tags} */
方法(Constructor & Methods)标签： /** * 函数功能说明 * ${user} ${date} * 修改者名字修改日期 * 修改内容 * @param ${tags} * @return ${return_type} * @throws */ getter方法标签： /** * @return ${bare_field_name} */ setter方法标签： /** * @param ${param} ${bare_field_name} */ 加注释快捷键：选中你要加注释的方法或类，按Alt + shift + J。
程序代码注释编写规范
程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"//"符号开始，任何位于该符号之后的本行文字都视为注释。 多行:以"/*"符号开始，以"*/"结束。任何介于这对符号之间的文字都视为注释。 一、说明性文件 说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* COPYRIGHT (C), MicTiVo International. Co., Ltd. File NAME: // 文件 Author: Version: Date: // 作者、版本及完成日期 DESCRIPTION: // 用于详细说明此程序文件完成的主要功能，与其他模块 // 或函数的接口，输出值、取值范围、含义及参数间的控 // 制、顺序、独立或依赖等关系 Others: // 其它内容的说明 Function List: // 主要函数列表，每条记录应包括函数名及功能简要说明 1.... History: // 修改历史记录列表，每条修改记录应包括修改日期、修改 // 者及修改内容简述 1. Date: Author: Modification: 2. .. *************************************************/ 二、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************ COPYRIGHT (C), MicTiVo International. Co., Ltd. FileName: Author:
Eclipse自动添加注释
Eclipse自动添加注释 我们在用Eclipse开发工具编写代码时，常常需要在类的头部加上一下注释，标明类的作者，创建时间等等。我们常用的做法是： 方式1：在新建类时勾选：Generate comments 如图1。 图1 创建类时指定生成注释 这种方式固然可以生成，但是只会是Eclipse默认的，仅有@author xxxx
方式2：快捷键生成 第二种就是我们生成类的时，也许忘了勾选。那么我们就会使用Eclipse提供的快捷键ctrl+alt+j 图2 快捷键添加注释 当然这种方式也需要开发者，现将鼠标定位类名行或者方法名行。然后生成对应的注释。那么如果我们想要自己定义自己的注释呢？ 方式三：自动生成自定义注释 Eclipse最大好处就是很多东西都能让开发者自己来定义。下面说说如何自定义生成注释。 3.1首先自定义注释模板 打开：windows-->preference -->Java-->code style -->code templates --> code -->new java file 按照如上操作打开到相应对话框，如下图3
图3：注释模板对话框 当进入到这个对话框后，点击右侧“Edit”编辑按钮，进入到注释模板编辑对话框，如下图4：
图4 编辑自定义注释模板 在这个对话框中编辑你想要的注释模板，编辑完成后点击OK。 附：注释基本模板： 当点击OK退出模板编辑对话框后，勾选：automatically add comments for new methods and types，如图5
图5 设置自动添加注释 当然，你还可以设置很多注释，包括getter、setter等等的注释，都在这里，有兴趣的你都可以多试试。
程序代码注释编写规范
程序代码注释编写规范 XXX份公司
为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"//"符号开始，任何位于该符号之后的本行文字都视为注释。 多行:以"/*"符号开始，以"*/"结束。任何介于这对符号之间的文字都视为注释。 一、说明性文件 说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* COPYRIGHT (C), MicTiVo International. Co., Ltd. File NAME: // 文件 Author: Version: Date: // 作者、版本及完成日期 DESCRIPTION: // 用于详细说明此程序文件完成的主要功能，与其他模块 // 或函数的接口，输出值、取值范围、含义及参数间的控 // 制、顺序、独立或依赖等关系 Others: // 其它内容的说明 Function List: // 主要函数列表，每条记录应包括函数名及功能简要说明 1.... History: // 修改历史记录列表，每条修改记录应包括修改日期、修改 // 者及修改内容简述 1. Date: Author: Modification: 2. .. *************************************************/ 二、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************
C语言编写规范之注释
1、头文件包含Includes 2、私有类型定义 Private typedef 3、私有定义Private define 4、私有宏定义 Private macro 5、私有变量 Private variables 6、私有函数原型Private function prototypes 7、私有函数Private functions 8、私有函数前注释 /****************************************************************************** * * Function Name : FSMC_NOR_Init * Description : Configures the FSMC and GPIOs to interface with the NOR memory. * This function must be called before any write/read operation * on the NOR. * Input : None * Output : None * Return : None ******************************************************************************* / 9、程序块采用缩进风格编写，缩进空格为4。 10、相对独立的程序块之间、变量说明之后必须加空行； 11、较长的字符（>80字符）要分成多行书写，长表达式要在低优先级操作符划分新行，操作符放在新行之首，新行要恰当缩进，保持排版整齐； 12、循环、判断等语句中若有较长的表达式或语句，则要进行适应的划分，长表达式要在低优先级操作符处划分新行，操作符放在新行之首; 13、若函数或过程中的参数较长，则要进行适当的划分。 14、不允许把多个短语句写在一行中，即一行只写一条语句。 15、if、for、do、while、case、switch、default等语句自占一行，且if、for、 do、while等语句的执行语句部分无论多少都要加括号{}。 16、对齐只使用空格键，不使用TAB键； 17、 函数或过程的开始、结构的定义及循环、判断等语句中的代码都要采用缩进风格，case 语句下的情况处理语句也要遵从语句缩进要求 18、 程序块的分界符（如C/C++语言的大括号‘{’和‘}’）应各独占一行并且位于同一 列，同时与引用它们的语句左对齐。在函数体的开始、类的定义、结构的定义、枚举的定义以 及if、for、do、while、switch、case语句中的程序都要采用如上的缩进方式。 19、 在两个以上的关键字、变量、常量进行对等操作时，它们之间的操作符之前、之后或
程序源代码注释规范
程序注释规范说明 程序注释规范应包括以下三方面： 一、文件头部注释 在代码文件的头部进行注释，这样做的好处在于，我们能对代码文件做变更跟踪。在代码头部分标注出创始人、创始时间、修改人、修改时间、代码的功能，这在团队开发中必不可少，它们可以使后来维护/修改的同伴在遇到问题时，在第一时间知道他应该向谁去寻求帮助，并且知道这个文件经历了多少次迭代、经历了多少个程序员的开发和修改。 样本： /***************************************************** ** 作者：Liuchao ** 创始时间：2007-11-12 ** 修改人：Liuchao ** 修改时间：2007-11-12 ** 修改人：Liaochao ** 修改时间：2007-11-12 ** 描述： ** 主要用于产品信息的资料录入，… *****************************************************/ 二、函数、属性、类等注释 请使用///三斜线注释，这种注释是基于XML的，不仅能导出XML制作帮助文档，而且在各个函数、属性、类等的使用中，编辑环境会自动带出注释，方便你的开发。以protected，protected Internal，public声明的定义注释都建议以这样命名方法。 例如： ///
/// 用于从ERP系统中捞出产品信息的类 /// class ProductTypeCollector { … } 三、逻辑点注释 在我们认为逻辑性较强的地方加入注释，说明这段程序的逻辑是怎样的，以方便我们自己后来的理解以及其他人的理解，并且这样还可以在一定程度上排除BUG。在注释中写明我们的逻辑思想，对照程序，判断程序是否符合我们的初衷，如果不是，则我们应该仔细思考耀修改的是注释还是程序了… 四、变量注释 我们在认为重要的变量后加以注释，说明变量的含义，以方便我们自己后来的理解以及其他人的理解，并且这样还可以在一定程度上排除BUG.我们常用///三斜线注释。 /// 用于从ERP系统中捞出产品信息的类 class ProductTypeCollector { int STData;///
软件总代码行数_软件注释率_分析
文档名称：软件总代码行数_软件注释 率分析 作者: 日期：
1. cncc 1.1 工具简介 度量工具名称cncc 网址https://www.wendangku.net/doc/604611864.html,/ 操作方式命令行 实现语言C++ 适用的操作系统Windows 可以度量的属性code-lines, empty-lines, comment-lines, total-lines 备注 1.2 工具优缺点总结 最新版本 cncc-1-3-1，在sourceforge中2004年已经停止更新。最大的优点是源代码全部存于一个cpp文件，便于集成。 缺点： 1.代码基本没有注释。 2.下载的代码编译有9个错误。 3.费了2个多小时也没搞定。 1.3 使用例程 无。 2. CodeCount 2.1 工具简介 度量工具名称CodeCount 网址https://www.wendangku.net/doc/604611864.html,/downloads421/sourcecode/windows
/control/detail1783204.html 操作方式GUI 实现语言C++ 适用的操作系统Windows 可以度量的属性total-lines, empty-lines, comment-lines, code-lines, 备注 2.2 工具优缺点总结 优点： 工具比较精简，统计源文件总行数、代码行数、空白行数、注释行数，代码有一定的注释。 缺点： 下载的源码是vc7工程，由于机器并没有vc7，利用工具进行工程类型转换，将vc7的工程转换为vc6的工作，编译出错。 核心代码如下： BOOL bCommentSet = FALSE; //注释行统计标识有"/*"时TRUE, "*/"时FALSE BOOL bQuatoSet = FALSE; //字符串统计标识首次一行有奇数个"时TRUE, 下一行有奇数个"时FALSE int nLength = (int)file.GetLength(); CString bufRead; int nLineCommentBegin = 0; while(file.ReadString(bufRead)!=FALSE) { BOOL bStatedComment = FALSE;//本行作为注释行是否已统计过 BOOL bStatedCode = FALSE; //本行作为代码行是否已统计过 nLines++; bufRead.TrimLeft(); //先将文件头的空格或制表符去掉 if(bufRead.GetLength()==0) //为空白行
java注释规范总结大全
在软件开发的过程中总是强调注释的规范，但是没有一个具体的标准进行说明，通常都是在代码编写规范中简单的描述几句，不能作为一个代码注释检查的标准和依据，做什么都要有一个依据吗:),现在我特整理了一个《Java的注释规范》，内容来自网络、书籍和自己的实际积累。 JA V A注释规范 版本/状态作者版本日期 1.0 ghc 2008-07-02 一、背景 1、当我们第一次接触某段代码，但又被要求在极短的时间内有效地分析这段代码，我们需要什么样的注释信息？ 2、怎么样避免我们的注释冗长而且凌乱不堪呢？ 3、在多人协同开发、维护的今天，我们需要怎么样的注释来保证高质、高交的进行开发和维护工作呢？ 二、意义 程序中的注释是程序设计者与程序阅读者之间通信的重要手段。应用注释规范对于软件本身和软件开发人员而言尤为重要。并且在流行的敏捷开发思想中已经提出了将注释转为代码的概念。好的注释规范可以尽可能的减少一个软件的维护成本, 并且几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护。好的注释规范可以改善软件的可读性，可以让开发人员尽快而彻底地理解新的代码。好的注释规范可以最大限度的提高团队开发的合作效率。长期的规范性编码还可以让开发人员养成良好的编码习惯，甚至锻炼出更加严谨的思维能力。 三、注释的原则 1、注释形式统一 在整个应用程序中，使用具有一致的标点和结构的样式来构造注释。如果在其他项目组发现他们的注释规范与这份文档不同，按照他们的规范写代码，不要试图在既成的规范系统中引入新的规范。 2、注释的简洁 内容要简单、明了、含义准确，防止注释的多义性，错误的注释不但无益反而有害。 3、注释的一致性 在写代码之前或者边写代码边写注释，因为以后很可能没有时间来这样做。另外，如果有机会复查已编写的代码，在今天看来很明显的东西六周以后或许就不明显了。通常描述性注释先于代码创建，解释性注释在开发过程中创建，提示性注释在代码完成之后创建。修改代码的同时修改相应的注释，以保证代码与注释的同步。 4、注释的位置 保证注释与其描述的代码相邻，即注释的就近原则。对代码的注释应放在其上方相邻或右方的位置，不可放在下方。避免在代码行的末尾添加注释；行尾注释使代码更难阅读。不过在批注变量声明时，行尾注释是合适的；在这种情况下，将所有行尾注释要对齐。 5、注释的数量 注释必不可少，但也不应过多，在实际的代码规范中，要求注释占程序代码的比例达到20%左右。注释是对代码的“提示”，而不是文档，程序中的注释不可喧宾夺主，注释太多了会让人眼花缭乱，注释的花样要少。不要被动的为写注释而写注释。 6、删除无用注释
Zdeveloper代码规范模板
Zdeveloper2.x代码规范1 ZDeveloper命名规范 常见JAVA包命名(以platform插件为例)。 2 公共包 plugins存放所有插件配置文件; lang存放所有插件国际化配置文件; JAVA存放所有插件java类文件; DB目录存放zdm文件。
3 一般情况java包 *.ui子包存放本插件所属UI类(*.ui省略前面的com.zving.platform,下同); *.service子包存放本插件所属扩展服务类; *.service.impl子包存放扩展服务项实现类; *.extend子包存放本插件扩展相关的类( 扩展点接口类或抽象类) ; *.extend.impl子包存放本插件扩展实现类( 扩展行为或其它扩展实现类) ; *.bl子包存放本插件所属后台业务逻辑类。 4 特殊扩展服务用到java包 *.code子包存放本插件所属扩展代码管理扩展服务的扩展项类; *.privilege子包存放本插件扩展菜单权限服务的扩展项类; *.config子包存放本插件扩展配置项扩展服务的扩展项类; *.properties子包存放本插件扩展栏目或站点配置项相关的扩展服务的扩展项类; *.tag子包存放本插件扩展标签服务的扩项类; *.tempalte子包存放本插件扩展模板服务的扩展项类;
( 插件包的命名参展以上方式, 项目需要能够酌情添加有一定意义的子包) 5 插件包 插件包统一以”com.zving.”+插件名称来命名(公司名称域名+插件名称)。 6 插件类 插件名称+”Plugin”, 位于插件所属包根目录下。 7 插件配置文件 ”com.zving.”+插件名称+”.plugin”。 8 UI类 页面名称+”UI”, 类存放位置为”com.zving.”+插件名称+”.ui”子包。
代码编写规范说明书
代码编写规范说明书（c#.net与https://www.wendangku.net/doc/604611864.html,）目录 1 目的 2 范围 3 注释规范 3.1 概述 3.2 自建代码文件注释 3.3 模块（类）注释 3.4 类属性注释 3.5 方法注释 3.6 代码间注释 4 命名总体规则 5 命名规范 5.1 变量（Variable）命名 5.2 常量命名 5.3 类（Class）命名 5.4 接口（Interface）命名 5.5 方法（Method）命名 5.6 名称空间Namespace）命名 6 编码规则 6.1 错误检查规则 6.2 大括号规则 6.3 缩进规则 6.4 小括号规则 6.5 If Then Else规则 6.6 比较规则 6.7 Case规则 6.8 对齐规则 6.9 单语句规则 6.10 单一功能规则 6.11 简单功能规则 6.12 明确条件规则 6.13 选用FALSE规则 6.14 独立赋值规则 6.15 定义常量规则 6.16 模块化规则 6.17 交流规则 7 编程准则 7.1 变量使用 7.2 数据库操作 7.3 对象使用 7.4 模块设计原则 7.5 结构化要求 7.6 函数返回值原则 8 代码包规范 8.1 代码包的版本号
8.2 代码包的标识 9 代码的控制 9.1 代码库/目录的建立 9.2 代码归档 10 输入控制校验规则 10.1 登陆控制 10.2 数据录入控制 附件1：数据类型缩写表 附件2：服务器控件名缩写表 1 目的 一.为了统一公司软件开发设计过程的编程规范 二.使网站开发人员能很方便的理解每个目录,变量，控件，类，方法的意义 三.为了保证编写出的程序都符合相同的规范，保证一致性、统一性而建立的程序编码规范。 四.编码规范和约定必须能明显改善代码可读性，并有助于代码管理、分类范围适用于企业所有基于.NET平台的软件开发工作 2 范围 本规范适用于开发组全体人员，作用于软件项目开发的代码编写阶段和后期维护阶段。 3 注释规范 3.1 概述 a) 注释要求英文及英文的标点符号。 b) 注释中，应标明对象的完整的名称及其用途，但应避免对代码过于详细的描述。 c) 每行注释的最大长度为100个字符。 d) 将注释与注释分隔符用一个空格分开。 e) 不允许给注释加外框。 f) 编码的同时书写注释。 g) 重要变量必须有注释。 h) 变量注释和变量在同一行，所有注释必须对齐，与变量分开至少四个“空格”键。 如：int m_iLevel,m_iCount; // m_iLevel ....tree level // m_iCount ....count of tree items string m_strSql; //SQL i) 典型算法必须有注释。 j) 在循环和逻辑分支地方的上行必须就近书写注释。 k) 程序段或语句的注释在程序段或语句的上一行 l) 在代码交付之前，必须删掉临时的或无关的注释。 m) 为便于阅读代码，每行代码的长度应少于100个字符。 3.2 自建代码文件注释 对于自己创建的代码文件（如函数、脚本），在文件开头，一般编写如下注释： /****************************************************** FileName: Copyright (c) 2004-xxxx *********公司技术开发部 Writer: create Date: Rewriter:
代码注释规范说明
Comments criterion of the Code 在多个PROJIECT共同开发的前提下，为了减少修改升级CODE过程中出现失误和方便SI 人员对代码的维护，加强部门整体代码注释规范，建议通过在每一次代码修改过程中添加代码标志符进行注释，这样可以使软件工程师在升级代码的过程中减少错误率，同时可以保持对以前版本代码的修改思路清晰，能在最短时间里复查代码中的错误。 标准C++/C的文件结构： // Copyright (c) Microsoft Corporation. All rights reserved. // Use of this source code is subject to the terms of the Microsoft end-user // license agreement (EULA) under which you licensed this SOFTWARE PRODUCT. // If you did not accept the terms of the EULA, you are not authorized to use // this source code. For a copy of the EULA, please see the LICENSE.RTF on your // install media. /** * Port Copyright (c) Hisys Corporation. All rights reserved. * @file batt_pdd.c * Abstract * This file contains battery driver PDD implementation. * Change Log * 2006.2.21 Shi Yuehua Initial Version * **/ 代码注释规范如下： //***********COMMENTS-HISTORY***********// /****************************************************************************** *NAME | SIGN | PROJECT | SUMMARY * *------------------------------------------------------------------------------ *Johson.Li M060806_A HXS006 Use the two methods to measure the battery voltage. *Johson.Li M060812_A HXS010 Change the init array value from 4 to 8. *Johson.Li M060812_B COMMON Change the USB CHANGING conditions. * ........... * ........... ******************************************************************************/ 代码注释标题声明包含四部分： 1.作者名称 2.标记符 3.项目名称 4.摘要 1.《NAME》：修改该部分CODE的软件人员名称（英文名称&中文名称拼音缩写），第一个字母大写。 2．《SIGN》：该标记符应在所有本次修改代码前面声明，主要是为了方便搜索，当我们想查找本次为了实现某个功能所做的代码修改时，可以搜索此标记符，即可找到全部修改过的相关代码段。 标记符：M060806_A M: 英文
idea,注释模板
竭诚为您提供优质文档/双击可除 idea,注释模板 篇一：idea快捷键 一常用快捷键 alt+回车导入包,自动修正，当引入的类需要异常捕获的时候 ctrl+shift+space自动补全代码,“new”字符,还可以引入强制转换的ctrl-alt-space可以自动导import类名或接口名提示,以及new后面的提示ctrl+n查找类 ctrl+shift+n查找文件 ctrl+shift+alt+n查找类中的方法或变量 ctrl+shift+alt+s:打开projectstructure ctrl+shift+F7选中文本，高亮显示所有该文本，按esc 高亮消失。ctrl+shift+F9编译类 ctrl+shift+F10运行类 crtl+shift++打开所有关闭的方法，crtl++打开当前关闭的方法 输入/**即可自(idea,注释模板)动写上该方法参数的注释
ctrl-shift-j快捷键把两行合成一行并把不必要的空 格去掉以匹配你的代码格式。ctrl-shift-V快捷键可以将最近使用的剪贴板内容选择插入到文本。使用时系统会弹出一个含有剪贴内容的对话框，从中你可以选择你要粘贴的部分。 ctrl+shift+up/down代码向上/下移动。 ctrl+shift+t自动创建测试类 ctrl+alt+s:打开settings ctrl+alt+l格式化代码 ctrl+alt+o优化导入的类和包 ctrl+alt+V快速为后面生成变量，如new或者方法的返回类型。ctrl+alt+left/right返回至上次浏览的位置ctrl-alt-b可以导航到一个抽象方法的实现代码。 ctrl-alt-t，选中某段代码，可以快速包围用if，try 等。在options|Filetemplates|codetab中你还可以自己定制产生捕捉块的模板。 alt+insert生成代码(如get,set方法,构造函数等) alt+shift+up/down代码向上/下移动。 alt+up/down在方法与类属性间快速移动定位 alt+F1查找代码所在位置 alt+1快速打开或隐藏工程面板 alt+left/right切换代码视图 alt+F3,选中文本，逐个往下查找相同文本，并高亮显
C 注释规范
C++注释规范 版本：1.0 制定部门：技术架构部C++基础架构组 2006.8
目录 1说明 (3) 2注释种类 (3) 2.1重复代码 (3) 2.2解释代码 (3) 2.3代码标记 (3) 2.4概述代码 (3) 2.5代码意图说明 (4) 2.6传达代码无法表达的信息 (4) 3注释原则 (4) 3.1站在读者的立场编写注释 (4) 3.2注释无法取代良好的编程风格 (4) 3.3好注释能在更高抽象层次上解释我们想干什么 (5) 4规范细则 (5) 4.1文件注释规范 (5) 4.2名字空间注释规范 (6) 4.3类定义注释规范 (7) 4.4数据声明注释规范 (8) 4.5函数注释规范 (8) 4.6代码标记注释规范 (10) 5FAQ (10) 5.1枚举值需要注释吗？ (10) 5.2前置条件、后置条件和不变式有必要注释出来吗？ (10) 5.3写注释太耗时间怎么办？ (11) 5.4有效的注释是指什么？ (11) 参考书目 (11) 参考工具 (11)
1说明 本文档用于规范C++代码中注释的编写。规范中提出的多数注释格式都来源于文档生成工具doxygen，所以遵从本规范进行注释的C++代码都可以使用doxygen生成美观一致的代码文档。 同时另一方面，美观绝非衡量文档质量的唯一标准。文档内容准确与否，是否充分，以及语言组织是否清晰流畅，这些都是决定一份文档质量的重要标准。遗憾的是，这些标准当中有不少需要通过主观加以判断，很难进行明确的规范。 所以我们将尽可能的提供明确的评判标准，同时，本规范中也不可避免的提出了一些比较主观的注释要求或是建议，这些要求或是建议多数都来自于众多先驱多年的开发经验。遵循它们不仅有助于生成一份美观的代码文档。更重要，依照这些要求和建议来编写注释，能够有效的帮助开发者在早期就反省自己设计的合理性，同时也为编写单元测试提供更多的帮助。 2注释种类 2.1重复代码 重复性注释只是用不同文字把代码的工作又描述一次。他除了给读者增加阅读量外，没有提供更多信息。 2.2解释代码 解释性注释通常用于解释复杂、敏感的代码块。在这些场合他们能派上用场，但通常正是因为代码含混不清，才体现出这类注释的价值。如果代码过于复杂而需要解释，最好是改进代码，而不是添加注释。使代码清晰后再使用概述性注释或者意图性注释。 2.3代码标记 标记性注释并非有意留在代码中，他提醒开发者某处的工作未做完。在实际工作中，我们经常会使用这些注释作为程序骨架的占位符，或是已知bug的标记。 2.4概述代码 概述性注释是这么做的：将若干代码行的意思以一两句话说出来。这种注释比重复性注释强多了，因为读者读注释能比读代码更快。概述性注释对于要修改你代码的其他人来说尤
华为代码规范文档
代码规范文档
目录 1 概述错误!未定义书签。 编写目的错误!未定义书签。 文档约定错误!未定义书签。 预期的读者和阅读建议错误!未定义书签。 参考文献错误!未定义书签。 2 排版要求错误!未定义书签。 程序块缩进错误!未定义书签。 程序块之间空行错误!未定义书签。 长语句和长表达式错误!未定义书签。 循环、判断等长表达式或语句错误!未定义书签。 长参数错误!未定义书签。 短语句错误!未定义书签。 条件、循环语句错误!未定义书签。 语句对齐错误!未定义书签。 函数、过程和结构等语句块错误!未定义书签。 程序块分界符错误!未定义书签。 操作符前后空格错误!未定义书签。 其他错误!未定义书签。 3 注释错误!未定义书签。 有效注释量错误!未定义书签。 公司标识错误!未定义书签。 说明性文件错误!未定义书签。 源文件头错误!未定义书签。 函数头部说明错误!未定义书签。 注释与代码一致错误!未定义书签。 注释内容错误!未定义书签。 注释缩写错误!未定义书签。 注释位置错误!未定义书签。 变量、常量注释错误!未定义书签。 数据结构的注释错误!未定义书签。 全局变量错误!未定义书签。 注释缩排错误!未定义书签。 注释与代码之间空行错误!未定义书签。 变量定义、分支语句错误!未定义书签。 其他错误!未定义书签。 4 标识符命名错误!未定义书签。 命名清晰错误!未定义书签。 特殊命名需注释错误!未定义书签。 命名风格保持一致错误!未定义书签。 变量命名错误!未定义书签。 命名规范与系统风格一致错误!未定义书签。 其他错误!未定义书签。 5 可读性错误!未定义书签。 运算符优先级错误!未定义书签。
论文要求及注释格式
《**文学》课程论文布置 总体要求： 1．以小论文方式完成； 2．为让同学认真准备，有足够时间完成，第10周即5月6号统一提交论文； 3．须交手写稿，不交电子稿。请学委按班级学号顺序统一整理后提交给教师； 4．教师阅读后会就作业进行课堂讲解； 5．期中成绩占期末总成绩的30%。请同学认真完成，如果对本次安排有意见或建议， 请及时提出，以便进行修改与改进。 评论**的小说《***》 说明与具体要求： 1．具体题目自行拟定。论文不必过于忧虑写得好坏，重在通过自己的努力，尝试了解、学习论文写作的基本规范与要求，为将来从事论文写作打下基础。 2．要探讨的论题主题不宜太大，要考虑可行性，尽量选一个角度深入研究。尤其注意 言之有据、充实而不发空论。不要写成读后感、作品欣赏或导读。 3．论文篇幅不少于2500字。 4．论文可以借鉴他人，但不能抄袭，用自己的语言和构思。 5．论文格式请参照我在网络教学平台教学材料中上传的学术论文，或者自行查找学习 知网上或图书馆、资料室专业杂志的论文。论文大体包括题目、摘要、关键词、主体、注释、参考文献等几个部分。 6．注意区别注释与参考文献。注释是指在文章中，具体引用了他人的观点、材料处的 注解。注释体例分文内注（在某处加括号的形式注明）、文末注、页脚注。本科生论文一般 以后两种为多，可以任选一种。参考文献一般指整篇文章曾经借鉴而不能或不必具体指出某 处的著作或文章。一般放在整篇论文后面。 7．以下附注释方式。大体可以作两种选择（以下以注释例说明），请根据自己的习惯选 择与学习。 注释方式一： 著作： 作者、著作名、出版者、出版年份、页码（这些要素的位置可以变动，但要求齐全并全文统一）
JAVA代码注释规范
JAVA代码注释规范 目录 JA V A代码注释规范 (1) 注释的原则 (1) 注释的简洁 (1) 注释的一致性 (1) 注释的位置 (2) 注释的数量 (2) 删除无用注释 (2) 复杂的注释 (2) 多余的注释 (2) 必加的注释 (3) JA V A注释技巧 (3) JA V A注释具体实现 (4) 源文件注释 (4) 类（模块）注释： (5) 接口注释： (5) 构造函数注释： (6) 方法注释： (6) 方法内部注释： (7) 全局变量注释： (7) 局部（中间）变量注释： (7) 常量 (7) p.s. 注释使用统一的注释文件 (8) 注释的原则 注释形式统一 在整个应用程序中，使用具有一致的标点和结构的样式来构造注释。如果在其他项目组发现他们的注释规范与这份文档不同， 按照他们的规范写代码，不要试图在既成的规范系统中引入新的规范。 注释的简洁 内容要简单、明了、含义准确，防止注释的多义性，错误的注释不但无益反而有害。 注释的一致性
在写代码之前或者边写代码边写注释，因为以后很可能没有时间来这样做。另外，如果有机会复查已编写的代码， 在今天看来很明显的东西六周以后或许就不明显了。通常描述性注释先于代码创建，解释性注释在开发过程中创建， 提示性注释在代码完成之后创建。修改代码的同时修改相应的注释，以保证代码与注释的同步。 注释的位置 保证注释与其描述的代码相邻，即注释的就近原则。对代码的注释应放在其上方相邻或右方的位置，不可放在下方。 避免在代码行的末尾添加注释；行尾注释使代码更难阅读。不过在批注变量声明时，行尾注释是合适的；在这种情况下，将所有行尾注释要对齐。 注释的数量 注释必不可少，但也不应过多，在实际的代码规范中，要求注释占程序代码的比例达到20%左右。注释是对代码的“提示”，而不是文档， 程序中的注释不可喧宾夺主，注释太多了会让人眼花缭乱，注释的花样要少。不要被动的为写注释而写注释。 删除无用注释 在代码交付或部署发布之前，必须删掉临时的或无关的注释，以避免在日后的维护工作中产生混乱。 复杂的注释 如果需要用注释来解释复杂的代码，请检查此代码以确定是否应该重写它。尽一切可能不注释难以理解的代码，而应该重写它。 尽管一般不应该为了使代码更简单便于使用而牺牲性能，但必须保持性能和可维护性之间的平衡。 多余的注释 描述程序功能和程序各组成部分相互关系的高级注释是最有用的，而逐行解释程序如何工作的低级注释则不利于读、写和修改，是不必要的， 也是难以维护的。避免每行代码都使用注释。如果代码本来就是清楚、一目了然的则不加注释，避免多余的或不适当的注释出现。
代码审查规范方案
代码审查规范 1. Code Review目的 Code Review是一种用来确认方案设计和代码实现的质量保证机制，通过这个机制我们可以对代码、测试过程和注释进行检查。 Code Review主要用来在软件工程过程中改进代码质量，通过Code Review可以达到如下目的： ?在项目早期就能够发现代码中的BUG。 ?帮助初级开发人员学习高级开发人员的经验，达到知识共享。 ?避免开发人员犯一些很常见，很普通的错误。 ?保证项目组人员的良好沟通。 ?项目或产品的代码更容易维护。 2. Code Review的前提条件 代码提交审核前，开发者必须确保代码符合如下条件，审核者需要确保所有前提条件都已满足方可开始审查，同时也是审查的主要检查点。 ?所有代码注释清晰，语法正确，编译通过。 ?日志代码完整，业务日志、系统日志分开，中文描述，脱敏处理，状态变更，全部清晰明确。 ?测试代码覆盖全部分支和流程，暂时统一使用工具Emma（各编译器可下载对应插件）进行Coverage Check。
?项目引用关系明确，依赖关系清晰，配置文件描述。 3. Code Review的审查范围 代码的一致性、编码风格、代码的安全问题、脱敏问题、代码冗余、是否正确设计以符合设计要求（性能、功能）与设计文档相同等等。 3.1、完整性检查（Completeness） ?代码是否完全实现了设计文档中所涉及的所有流程和功能点 ?代码是否已包含所有所需的业务日志、系统日志、异常日志，日志内容是否完整，日志文件配置是否正确。 ?代码是否使用缓存等，配置信息是否正确可配置。 ?代码中是否存在任何没有定义或没有引用到的变量、常数或数据类型等 3.2、一致性检查（Consistency） ?代码的逻辑是否符合设计文档 ?代码中使用的格式、符号、结构等风格是否保持一致 3.3、正确性检查（Correctness） ?代码是否符合制定的标准 ?所有的变量都被正确定义和使用 ?所有的注释都是准确的 ?所有的程序调用都使用了正确的参数个数