金山学院文件
C/C++源代码书写规范
金山软件股份有限公司
金山学院
2009年6月
目录前言
1.文件起始处的说明
2.关于注释
3.每行代码长度
4.合并行的问题
5.指针中*号的位置
6.全局函数的调用
7.关于if...else if
8.与“{”、“}”有关的各项规定
9.与空格有关的各项规定
10.与缩进有关的各项规定
11.关于出错处理
12.与类相关的.h文件与.cpp文件
13.注释书写与自动生成帮助文档规范附录一命名规范
附录二通用缩写表
前言
本规范规定了C/C++源代码的书写规范。
制定本规范的目的是统一金山学院的C/C++语言源代码的书写风格，以便于代码的阅读、维护、管理及修订。
本规范于2008年1月由金山学院制定，并于同月实施。从实施之日起，学院学员的所有C/C++语言源代码都必须遵从本规范进行书写。
本规范以《金山研究院文件——C/C++源代码书写规范》(2004年4月版)为蓝本，根据学院实际情况进行一定的调整。
C/C++源代码书写规范
1文件起始处的说明
在.h/.cpp的开头应有一段格式统一的说明，内容包括：
·文件名(FileName)；
·创建人(Creator)；
·文件创建时间(Date)；
·简短说明文件功能、用途(Comment)。
例：
///////////////////////////////////////////////////////////////
//
//FileName:KSample.h
//Creator:John Doe
//Date:2004-2-421:42:54
//Comment:
//
/////////////////////////////////////////////////////////////// 2关于注释
除非极其简单，否则对函数应有注释说明。内容包括：功能、入口/出口参数，必要时还可有备注或补充说明。
2.1推荐采取特定的格式(见第14条)，以方便用软件自动生成帮助文档。
2.2对于if、while、do等其大括号内嵌代码块比较长(需拖动滚动条来看)或者多层
嵌套时，在结尾的“}”后要加上其所对应的语句的注释说明。
例：
if((isWindow==TRUE)&&(isVisible==true))
{
代码段
}//if((isWindow==TRUE)...
2.3函数入口参数有缺省值时，应注释说明。
例：
BOOL KSSaveToFile(
const char cszFileName[],
BOOL bCanReplace/*=TRUE*/
);
或者：
BOOL KSSaveToFile(
const char cszFileName[],
BOOL bCanReplace//=TRUE
);
2.4描述某个代码段的注释，可以给注释描述的代码段外围加上{}，帮助阅读。
例：
//代码段实现功能或意图描述
{
代码段
}
3每行代码长度
每行代码的长度推荐为80个ASCII字符，最长不得超过120；折行以对齐为准。
例：
HANDLE KSOpenFile(const char cszFileName[],
int nMode);
或者：
BOOL KSReadFile(
HANDLE hFile,
void*pvBuffer,
int nReadSize,
int*pnReadSize
);
4合并行的问题
循环、分支代码，判断条件与执行代码不得在同一行上。
例：
正确：
if(n==-2)
n=1;
else
n=2;
不得写做：
if(n==-2)n=1;
else n=2;
5指针中*号的位置
指针的定义，*号既可以紧接类型，也可以在变量名之前。
例：
可写做：int*pnsize;
也可写做：int*pnsize;
但不得写做：int*pnsize;
6全局函数的调用
在类的成员函数内调用全局函数时，在全局函数名前必须加上“::”。
7关于if...else if
else if必须写在一行。
8与“{”、“}”有关的各项规定
8.1在“{”之前不允许有除空格与Tab之外的其他任何字符；在它之后可有注释，但
不允许有代码。与“{”对应的“}”必须在同一列上。
例：
正确：
for(i=0;i {//..... printf("Line%d:",i); printf("%s\n",pFileLines[i]); } 不得写做： for(i=0;i {printf("Line%d:",i); printf("%s\n",pFileLines[i]); } 也不得写做： for(i=0;i printf("Line%d:",i); printf("%s\n",pFileLines[i]); } 8.2在循环、分支之后若只有一行代码，在无歧义的情况下可省略“{”、“}”。 例： if(n==-2) n=1; else n=2; 9与空格有关的各项规定 9.1在所有两目、三目运算符的两边都必须有空格。在单目运算符两端不必空格。但在 “->”、“::”、“.”、“[”、“]”等运算符前后，及“&”（取地址）、“*”（取值）等运 算符之后不得有空格。 例： 正确： int n=0,nTemp; for(int i=nMinLine;i<=nMaxLine;i++) 不得写做： int n=0,nTemp; for(int i=nMinLine;i<=nMaxLine;i++) 9.2for、while、if等关键字之后应有1个空格，再接“(”。 例： 正确： if(-2==n) 不得写做： if(-2==n) 9.3调用函数、宏时，“(”前不得有空格。 例： 正确： printf("%d\n",nIndex); 不得写做： printf("%d\n",nIndex); 9.4类型强制转换时，“(”“)”前后不得有空格 例： 可写做： (KSFile*)pFile; 也可写做： (KSFile*)pFile 不得写做： (KSFile*)pFile (KSFile*)pFile 10与缩进有关的各项规定 10.1缩进以Tab为单位。要求在编辑器中将1个Tab设置为4个空格宽度。 10.2下列情况，代码缩进一个Tab： 1.函数体相对函数名及“{”、“}”。 例： int Power(int x) { return(x*x); } 2.if、else、for、while、do等之后的代码。 3.一行之内写不下，折行之后的代码，应在合理的位置进行折行。若有+-*/ 等运算符，则运算符应在上一行末尾，而不应在下一行的行首。 10.3下列情况，不必缩进：switch之后的case、default。 例： switch(nID) { case ID_PLAY: ...... break; case ID_STOP: ...... break; default: ...... break; } 11关于出错处理 本规范对此不做特别规定。但要求项目组在开始编码前必须为项目定义明确的出错处理规范。 12与类相关的.h文件与.cpp文件 12.1原则上，应该在一个单独的.h文件中定义一个类，在一个单独的.cpp文件中实现 这个类。.h与.cpp文件的文件名必须与类名相同。 12.2若几个类的规模都不大，关系又很密切，则可在一个.h文件中定义这些类，在一 个.cpp文件中实现。对于附属于较大规模类的一个很小规模的类，可以写在那 个大规模类的.h和.cpp里。 13注释书写与自动生成帮助文档规范 13.1以下的注释规范用于自动生成帮助文档，自动生成文档工具为Doxygen。对于 那些不希望提取为帮助文档的注释，不在本规范规定的范围内。 13.2块注释 [格式] 开头：/** 结尾：*/ 例： /** *...This is a block comment... */ 13.3行注释 [格式] 开头：/// 例： ///This is a line comment... 13.4函数的摘要 [格式] 在函数声明主体开头的注释块中加上控制符：@brief 例： /** *@brief用于从输入流读取一个字符，不回显 */ int getch(void); 13.5函数的形参 [格式] 在函数声明主体开头的注释块中加上控制符：@param 例： /** *@param buf1缓冲区1 *@param buf2缓冲区2 *@param count字符的个数 */ int memcmp(const void*buf1,const void*buf2,size_t count); 13.6函数的返回值 [格式] 在函数声明主体开头的注释块中加上控制符：@return 例1： /** *@return读取的字符 */ int getchar(void); 例2： /** *@return None */ void rewind(FILE*stream); 13.7函数的注意事项（Remark） [格式] 在函数声明主体开头的注释块中加上控制符：@remark 例： /** *@remark拷贝strSource到strDestination（包含strSource中的'\0'）， 要注意在拷贝的过程中并没有溢出检查 */ char*strcpy(char*strDestination,const char*strSource); 13.8补充说明 更多的格式请参考Doxygen文档，因为有些高级的选项比较繁琐。编写注释 的目的是为了方便自动生成文档，而在此基础上又不能使程序员过于分散精 力。Doxygen的文档自动生成功能非常强大，很多事情都不需要手工干预，我们只要用到最基本的几项功能也可以满足需求了。 附录一命名规范 本规范给出了工程、文件、函数、变量、类/结构、宏、常量、枚举、联合等的命名规范。 通则： 1所有命名都应使用标准的英文单词或缩写，不得使用拼音或拼音缩写，除非该名字描述的是中文特有的内容，如半角、全角、声母、韵母等。 2所有命名都应遵循达意原则，即名称应含义清晰、明确。 3所有命名都不易过长，应控制在规定的最大长度以内。 4所有命名都应尽量使用全称。 5如果命名使用缩写，则应该使用《通用缩写表》(见附录二)中的缩写；原则上不推荐使用《通用缩写表》以外的缩写，如果使用，则必须对其进行注释和说明。 具体规范： 1工程名： 不强制统一。 2文件名： ·只能由英文字母、数字和下划线组成文件名。 ·区分大小写，基于跨平台的考虑，建议全小写。 ·长度不限于8.3格式，建议不多于30个字符。 ·如果文件用于定义或实现类，则文件名与类名必须保持一致。 3函数名： ·参照Windows API的命名规范。 ·函数名最长不得超过64个字符。 ·推荐使用动宾结构。函数名应清晰反映函数的功能、用途。 ·推荐函数名第一个字母大写。 4变量名： 原则上，变量的命名遵从匈牙利记法。即：前缀+类型+名称。最终的变量名总长不得超过32个英文字符。 1）格式： [m_|s_|g_]type[class name|struct name]variable name 2）解释： ·m_：类的成员变量 ·ms_：类的静态成员变量 ·s_：静态全局变量 ·g_：普通全局变量 ·类型缩写（type） ·char,TCHAR：ch ·字符串：sz ·bool,BOOL：b ·int,__int16,__int32,__int64：n ·unsigned：u ·long：l ·unsigned long：ul ·double，float：f ·BYTE：by ·WORD：w ·DWORD：dw ·function：fn ·pointer：p ·object：k 小范围局部变量与结构成员可省略类型缩写 5类名： ·必须以大写"K"开头，后面字母反映具体含义，以清晰表达类的用途和功能为原则。 ·接口必须以大写"I"开头，代表Interface。 ·当名称由多个单词构成时，每一个单词的第一个字母必须大写。 6结构、宏、枚举以及联合的名字必须全部大写。 附录二通用缩写表 说明： 1本缩写表中列出的都是通用性缩写，不提供标准缩写，如：Win9x、COM等。2使用本缩写表里的缩写时，请对其进行必要的注释说明。 3除少数情况以外，大部分缩写与大小写无关。 通用缩写表 //根据半径计算圆的周长和面积#include Git源代码管理规范 一、分支管理 使用git进行源代码管理, 一般将某个项目的所有分支分为以下几条主线: 1.Master 顾名思义, 既然名字叫Master, 那么该分支就是主分支的意思。master分支永远是production-ready的状态, 即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了, 不论是要做新的feature还是需要做bug fix, 都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本, 即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后, 就会合并到develop分支去。 4.release branches 这个分支系列从develop分支出来, 也就是预发分支。在预发状态下, 我们往往会进行预发环境下的测试, 如果出现缺陷, 那么就在该release分支下进行修复, 修复完毕测试经过后, 即分别并入master分支后develop分支, 随后master分支做正常发布。 5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复, 当线上出现bug且特别紧急的时候, 就能够从master拉出分支到这里进行 修复, 修复完成后分别并入master和develop分支。 下面这张图将完整展示这一个流程 二、工作原理Git的工作方式: 也就是说, 每次提交版本变动的时候, git会保存一个快照(snapshot)。如果文件没有被更改, git也不会再次保存, 而是提供一个到原来文件的链接。这样一来, git更像是一个小型的文件系统。另外, git的所有操作都能够是本地的, 仅仅在将新版本的内容上传到服务器上时才需要连接网络。 Git目录( repository) 是Git保存元数据和对象数据库的地方。这也是Git最重要的部分。 数控机床标准G、M代码 一．准备功能字G 准备功能字是使数控机床建立起某种加工方式的指令，如插补、刀具补偿、固定循环等。G功能字由地址符G和其后的两位数字组成，从G00—G99共100种功能。JB3208-83标准中规定如下表： 代码功能 作用范 围 功能 代码 功能作用范围功能 G00 点定位 G50 * 刀具偏置0/- G01 直线插补 G51 * 刀具偏置+/0 G02 顺时针圆弧插补 G52 * 刀具偏置-/0 G03 逆时针圆弧插补 G53 直线偏移注销 G04 * 暂停 G54 直线偏移 X G05 * 不指定 G55 直线偏移Y G06 抛物线插补 G56 直线偏移Z G07 * 不指 定 G57 直线偏移XY G08 * 加速 G58 直线偏移XZ G09 * 减速 G59 直线偏移YZ G10-G16 * 不指定 G60 准确定位（精） G17 XY平面选 择 G61 准确定位（中） G18 ZX平面选择 G62 准确定位（粗） G19 YZ平面选择 G63 * 该丝 G20-G32 * 不指定 G64-G67 * 不指定 G33 螺纹切削，等螺距 G68 * 刀具偏置，内角 G34 螺纹切削，增螺距 G69 * 刀具偏置，外角 G35 螺纹切削，减螺距 G70-G79 * 不指定 G36-G39 * 不指定 G80 固定循环注销 G40 刀具补偿/刀具偏置 注销 G81-G89 固定循环 G41 刀具补偿--左 G90 绝对尺寸 G42 刀具补偿-- 右 G91 增量尺寸 G43 * 刀具偏置--正 G92 * 预置寄存 G44 * 刀具偏置--右 G93 进给率，时间倒数 G45 * 刀具偏置+/+ G94 每分钟进给 G46 * 刀具偏置+/- G95 主轴每转进给 G47 * 刀具偏置-/- G96 恒线速 度 G48 * 刀具偏置-/+ G97 每分钟转数（主轴） G49 * 刀具偏置0/+ G98-G99 * 不指定 注：*表示如作特殊用途，必须在程序格式中说明二．辅助功能字M 目录 一．规范简介 1.1 目的 所有的程序开发手册都包含了各种规则。一些习惯自由程序人员可能对这些规则很不适应，但是在多个开发人员共同写作的情况下，这些规则是必需的。这不仅仅是为了开发效率来考虑，而且也是为了后期维护考虑。 本规范正是为培养规范设计和编程，养成良好的习惯，增强软件产品的稳定，健壮，可靠性；同时也为了提高软件的可读性，可以让程序员尽快而彻底地理解新的代码，使产品可维护性提高而制定的规范。 1.2 开发规范的重要性 （1）减少维护成本； 一个软件的生命周期中，80%的花费在于维护，另一方面，几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护，规范的编码减少人员变动带来的维护成本。 （2）改善软件的可读性 可以让程序员尽快而彻底地理解新的代码。在一个团队中，代码也容易在程序员之间共享。 （3）维护部门交付产品的规范形象。 二．具体规范 2.1 注释 注释是软件可读性的具体表现。程序注释量一般占程序编码量的20%，软件工程要求不少于20%。程序注释不能用抽象的语言，要精确表达出程序的处理说明。避免每行程序都使用注释，可以在一段程序的前面加一段注释，具有明确的处理逻辑。 注释必不可少，但也不应过多，不要被动得为写注释而写注释。 2.1.1 需要注释的部分 （1）文件头注释，文件创建及修改记录，版权归属，作者以及修订者，以及对文件的简短描述。 （2）类的目的（即类所完成的功能）、设置接口的目的以及应如何被使用。 （3）成员方法注释（对于设置与获取成员方法，在成员变量已有说明的情况下，可以不加注释；普通成员方法要求说明完成功能，参数含义以及返回值）。 （4）普通成员方法内部注释（控制结构、代码所起到的作用以及如此编写代码的原因，处理顺序等）。 （4）参数的含义以及其他任何约束或前提条件、字段或属性描述。而对于局部变量，如无特别意义的情况下则不加注释。 2.1.2 具体注释 （1）文件头注释 要求：遵循JavaDoc的规范，在每一个源文件的开头注明该文件的作用, 作简要说明, 并写上源文件的作者,版权信息编写日期。如果是修改别人编写的源文件，要在修改信息上注明修改者和修改日期。 例子： /** * @Title: 文件名 * @Copyright (C) 年份龙图软件 * @Description: 文件信息描述 * @Revision History: * @Revision 版本号日期作者. */ （2）类和接口的注释 要求：遵循JavaDoc的规范，在每一个类的开头注明该类的作用，作简要说明，并写上作者，编写日期。 例子： /** * @ClassName: 类（或接口）名 * @Description: Description of this class ------------------------------------------------------------------------摘自宋鲁生程序设计大赛 乘法口诀表 #include 用一维数组统计学生成绩 #include C 经典程序代码大全 #include const float PI= 3.1416; //声明常量(只读变量)PI为 3.1416 float fCir_L(float); //声明自定义函数fCir_L()的原型 float fCir_S(float); //声明自定义函数fCir_S()的原型 //以下是main()函数 main() { float r,l,s; //声明3个变量 cout>r; //键盘输入 l=fCir_L(r); //计算圆的周长，赋值给变量l s=fCir_S(r); //计算圆的面积，赋值给变量s cout=0.0) //如果参数大于0，则计算圆的周长 z=2*PI*x; return(z); //返回函数值 } //定义计算圆的面积的函数fCir_S() float fCir_S(float x) { float z=- 1.0; //声明局部变量 if (x>=0.0) //如果参数大于0，则计算圆的面积 z=PI*x*x; return(z); //返回函数值 } /* Program: P1- 2.CPP Written by: Hap Date written: 02:11:10 */ #include void main(void) { double s1,s2,s3; s1= 1.5; /* 对变量s1赋值*/ cout main() { double r= 1.0; cout>r; //键盘输入 l=2* 3.1416*r; //计算圆的周长，赋值给变量l cout //包含iostream.h头文件 void main() { //输出字符常量.变量和字符串 char c1= A ; cout //包含iostream.h头文件 main() { //输入输出字符 char c; cin>>c; cout>n; cout>x; cout>n; cout>c>>n>>x; cout //包含iostream.h头文件 main() { //声明整型变量 int a,b; //从键盘上为整型变量赋值cout>a; cout>b; //整型数的算术运算 cout //包含iostream.h 头文件 main() { //声明变量，并初始化 int a=010,b=10,c=0X10; //以进制形式显示数据 cout>a; cout>b; cout>c; cout //包含iostream.h头文件 #include // iomanip.h头文件包含setprecision()的定义 main() { //float型变量的声明.输入.计算和输出 float fx,fy; cout>fx; cout>fy; cout>dx; cout>dy; cout //包含iostream.h 头文件 main() { //字符类型变量的声明 char c1= A ; char c2; //字符数据的运算及输出 c2=c1+32; cout>c1>>c2; cout //包含iostream.h头文件 main() { char c1= \a ,TAB= \t ; //阵铃一声 cout //包含iostream.h头文件 main() UI设计（代码）规范 一．目录结构与命名规则 （1）目录结构规范 1、目录建立的原则：以最少的层次提供最清晰简洁的页面结构。 2、根目录一般只存放index.htm以及其他系统必须的文件 3、在根目录中应该按照系统的栏目结构，给每一个栏目开设一个目录，根据需要在每一个栏目的目录中开设一个images 和media 的子目录用来放置此栏目专有的图片和多媒体文件，如果这个栏目的内容特别多，又分出很多下级栏目，可以相应的再开设其他目录。根目录下的images用于存放各页面都要使用的公用图片，子目录下的images目录存放本栏目页面使用的私有图片 4、所有JS,ASP,PHP等脚本存放在根目录下的scripts目录 5、所有CGI程序存放在根目录下的cgi-bin目录 6、所有CSS文件存放在根目录下style目录 7、每个语言版本存放于独立的目录。例如：简体中文gb 8、所有flash, avi, ram, quicktime 等多媒体文件存放在根目录下的media目录 9、temp 子目录放客户提供的各种文字图片等等原始资料，以时间为名称开设目录，将客户陆续提供的资料归类整理。 （2）文件和目录命名规范 1、文件命名的原则：以最少的字母达到最容易理解的意义。 2、每一个目录中包含的缺省html 文件，文件名统一用index.htm 3、文件名称统一用小写的英文字母、数字和下划线的组合，不得包含汉字、空格和特殊字符 4、尽量按单词的英语翻译为名称。例如：feedback(信息反馈)，aboutus(关于我们) 不到万不得已不要以拼音作为目录名称 5、多个同类型文件使用英文字母加数字命名，字母和数字之间用_分隔。例如：news_01.htm。注意，数字位数与文件个数成正比，不够的用0补齐。例如共有200条新闻，其中第18条命名为news_018.htm （3）图片的命名规范 1、名称分为头尾两两部分，用下划线隔开。 2、头部分表示此图片的大类性质。 例如：放置在页面顶部的广告、装饰图案等长方形的图片我们取名：banner ；标志性的图片我们取名为：logo ；在页面上位置不固定并且带有链接的小图片我们取名为button ；在页面上某一个位置连续出现，性质相同的链接栏目的图片我们取名：menu ；装饰用的照片我们取名：pic ；不带链接表示标题的图片我们取名：title 依照此原则类推。 3、尾部分用来表示图片的具体含义，用英文字母表示。例如：banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg pic_hill.jpg. （4）css的命名规范 1，全局定义 /*{}（大括号）内为空时，除ul元素外，其他均自己定义*/ body,ul,ol,p,span,dd,dt,h1,h2,h3,h4,h5,h6{ margin:0px; padding:0px;}/*初始化元素的内联及外联*/ div{ overflow:hidden} 源代码管理制度 1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 1.3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。在SVN库中设置用户，并为不同用户分配不同的权限，适合工作的最小访问权限。 要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。 2、曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 1.4代码版本管理 1、终端软件的版本标识管理 终端软件版本由终端型号、版本号和内部修订号来进行标识。终端型号：终端型号是硬件标识号，也唯一的标识了我们的项目。版本号：由“＜主版本号＞.＜次版本号＞.＜修订号＞”三段组成，中间是点号分开。版本号的目的主要是管理终端软件的对外发布，终端软件的bug的记录和统计，主要是针对于版本号的，测试部、项目部、客户等会记录某个版本号的终端软件存在哪些bug，bug会在哪个版本号中得到修正。终端软件一个新的版本号出来后，我们会统计新的版本号解决了上一个版本号中的哪些bug，以及增加了哪些新功能，等等。 内部修订号：也就是“应用程序的源代码的svn修订号”，主要是由软件部和测试部内部来使用，内部修订号唯一标识我们的终端软件，即：通过内部修订号能够唯一的找出我们发布的终端软件所对应的全部软件源代码，目的是为了软件排错使用。 另外，终端软件在发布时，还会给出发布日期，以便开发、测试、项目、客户等相关人员参考。 2、终端软件版本发布管理 终端软件主要是以版本号为基准，对外发布，目前采用不定时发布策略，发布的时间由软件部、项目部和客户方根据情况，共同商量决定。 由于目前项目时间紧，终端软件无法得到完整的测试就要发布，在发布之后，有一些需要紧急需要修复的bug，软件部需要紧急修复后就要发布更新包，以便用户能够使用，所以，在一个版本号发布后，需要进行多次修订，对于这些修订的版本，其版本号保持不变，内部修订发生变化。 3、软件bug记录、管理和统计 软件bug的记录、管理和统计主要以版本号为基准，但为了软件开发人员能够找到bug 1. 数控程序中字母的含义 O：程序号，设定程序号 N：程序段号，设定程序顺序号 G：准备功能 X/Y/Z ：尺寸字符，轴移动指令 A/B/C/U/V/W：附加轴移动指令 R：圆弧半径 I/J/K：圆弧中心坐标（矢量） F：进给，设定进给量 S：主轴转速，设定主轴转速 T：刀具功能，设定刀具号 M：辅助功能，开/关控制功能 H/D：刀具偏置号，设定刀具偏置号 P/X：延时，设定延时时间 P：程序号指令，设定子程序号（如子程序调用：M98P1000） L：重复，设定子程序或固定循环重复次数（如：M98 P1000 L2，省略L代表L1）P/W/R/Q：参数，固定循环使用的参数(如：攻牙G98/(G99)G84 X_ Y_ R_ Z_ P_ F_) 2. 常用G代码解释 G00：定位或快速移动 G01：直线插补 G02：圆弧插补/螺旋线插补CW G03：圆弧插补/螺旋线插补CCW G04：停留时间或延时时间 如：G04 X1000(或G04 X1.0) G04 P1000表示停留1秒钟 G09：准确停止或精确停止检查（检查是否在目标范围内） G10：可编程数据输入 G17：选择XPYP 平面 XP：X 轴或其平行轴 G18：选择ZPXP 平面 YP：Y 轴或其平行轴 G19：选择YPZP 平面 ZP：Z 轴或其平行轴 G20：英寸输入 G21：毫米输入 G28：返回参考点检测 格式：G91/(G90) G28 X__ Y__ Z__ 经过中间点X__ Y__ Z__返回参考点(绝对值/增量值指令) G29：从参考点返回 G91/(G90) G29 X__ Y__ Z__ 从起始点经过参考点返回到目标点X__ Y__ Z__的指令(绝对值/增量值指令) G30 返回第2，3，4 参考点 G91/(G90) G30 P2 X__ Y__ Z__；返回第2 参考点（P2 可以省略。） G91/(G90) G30 P3 X__ Y__ Z__；返回第3 参考点 1源代码管理 (1) 总则 (1) 源代码完整性保障 (1) 源代码的授权访问 (2) 代码版本管理 (2) 源代码复制和传播 (5) 系统测试验收流程 (5) 系统初验 (6) 试运行 (6) 系统终验 (6) 应用系统验收标准 (8) 文档评审通过标准 (9) 确认测试通过标准 (9) 系统试运行通过标准 (10) 1代码管理 总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 程序设计规范 一、程序风格： 1、严格采用阶梯层次组织程序代码： 各层次缩进的分格采用VC的缺省风格，即每层次缩进为4格，括号位于下一行。要求相匹配的大括号在同一列，对继行则要求再缩进4格。例如： 2、提示信息字符串的位置 在程序中需要给出的提示字符串，为了支持多种语言的开发，除了一些给调试用的临时信息外，其他所有的提示信息必须定义在资源中。 3、对变量的定义，尽量位于函数的开始位置。 二、命名规则： 1、变量名的命名规则 ①、变量的命名规则要求用“匈牙利法则”。即开头字母用变量的类型，其余部分用变量的英文意思或其英文意思的缩写,尽量避免用中文的拼音,要求单词的第一个字母应大写。即：变量名=变量类型+变量的英文意思（或缩写） 对非通用的变量，在定义时加入注释说明，变量定义尽量可能放在函数的开始处。 见下表： bool(BOOL) 用b开头bIsParent byte(BYTE) 用by开头byFlag short(int) 用n开头nStepCount long(LONG) 用l开头lSum char(CHAR) 用c开头cCount float(FLOAT) 用f开头fAvg double(DOUBLE) 用d开头dDeta void(VOID) 用v开头vVariant unsigned int（WORD）用w开头wCount unsigned long(DWORD) 用dw开头dwBroad HANDLE（HINSTANCE）用h开头hHandle DWORD 用dw开头dwWord LPCSTR(LPCTSTR) 用str开头strString 用0结尾的字符串用sz开头szFileName 对未给出的变量类型要求提出并给出命名建议给技术委员会。 ②、指针变量命名的基本原则为： 对一重指针变量的基本原则为： “p”+变量类型前缀+命名 如一个float*型应该表示为pfStat 对多重指针变量的基本规则为： 二重指针：“pp”+变量类型前缀+命名 三重指针：“ppp”+变量类型前缀+命名 ...... ③、全局变量用g_开头,如一个全局的长型变量定义为g_lFailCount,即：变量名=g_+变量类型+变量的英文意思（或缩写） 代码管理制度 1总则 (2) 2源代码完整性保障 (2) 3源代码的授权访问 (2) 4代码版本管理 (3) 5源代码复制和传播 (4) 6系统测试验收流程 (5) 6.1 系统初验 (5) 6.2 试运行 (5) 6.3 系统终验 (5) 6.4 系统验收标准 (6) 6.5 文档评审通过标准 (7) 6.6 确认测试通过标准 (7) 6.7 系统试运行通过标准 (7) 1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。 XXXXXXXX 代码版本管理规范 历史版本 目录 历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9) 1引言 1.1目的 为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 1.2管理工具 沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。 2现状概述 目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。 这样会造成如下两点影响： ●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库 中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 ●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部 分问题是由于其他项目代码引起的。 因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述 当前代码版本管理现状如下： 1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的 代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。 这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。 总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试 VB编程常用代码大全 1.数值型函数： abs(num): 返回绝对值 sgn(num): num>0 1; num=0 0; num<0 -1;判断数值正负 hex(num): 返回十六进制值直接表示：&Hxx 最大8位 oct(num): 返回八进制值直接表示：&Oxx 最大8位 sqr(num): 返回平方根 num>0 int(num): 取整 int(99.8)=99; int(-99.2)=100 fix(num): 取整 fix(99.8)=99; fix(-99.2)=99 round(num,n): 四舍五入取小数位 round(3.14159,3)=3.142 中点数值四舍五入为近偶取整 round(3.25,1)=3.2 log(num): 取以e为底的对数 num>0 exp(n): 取e的n次幂通常用 num^n sin(num): 三角函数，以弧度为值计算 (角度*Pai)/180=弧度 con(num); tan(num); atn(num) 2.字符串函数： len(str)：计算字符串长度中文字符长度也计为一！ mid(str,起始字符,[读取长度])：截取字符串中间子字符串 left(str,nlen)：从左边起截取nlen长度子字符串 right(str,nlen)：从右边起截取nlen长度子字符串 Lcase(str)：字符串转成小写 Ucase(str)：字符串转成大写 trim(str)：去除字符串两端空格 Ltrim(str)：去除字符串左侧空格 Rtrim(str)：去除字符串右侧空格 replace(str,查找字符串,替代字符串,[起始字符,替代次数,比较方法])：替换字符串 注：默认值：起始字符 1；替代次数不限；比较方法区分大小写（0） InStr([起始字符,]str,查找字符串[,比较方法])：检测是否包含子字符串可选参数需同时选返回起始位置 InStrRev(str,查找字符串[,起始字符][,比较方法])：反向检测是否包含子字符串返回起始位置 space(n)：构造n个空格的字符串 string(n,str)：构造由n个str第一个字符组成的字符串 StrReverse(str)：反转字符串 split(str,分割字符串[,次数][,比较方法])：以分割字符串为分割标志将字符串转为字符数组可选参数需同时选 1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10) 1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。C程序代码大全
Git源代码管理规范样本
数控编程G、M、T、S代码大全(精选.)
代码规范
C语言代码大全
C 经典程序代码大全
CSS设计(代码)规范
源代码管理制度
CNC加工中心程序代码大全
源代码管理规范
程序设计规范
源代码管理规范
代码版本管理规范_v1.1
VB编程常用代码大全
源代码管理规范
相关主题
文本预览