目录
1 编程风格 (1)
1.1 统一编程风格的意义 (1)
1.2 变量命名的规则 (1)
1.3 函数的命名规范 (3)
1.4 函数参数规范 (3)
1.5 引出函数规范 (4)
1.6注释规范 (4)
2 代码组织 (5)
3 代码优化 (6)
3.1 代码优化的意义 (6)
3.2代码优化的方法 (6)
4 调试技巧 (7)
4.1静态检查 (7)
4.2 上机调试 (7)
4.3 C语言常见问题 (8)
1 编程风格
1.1 统一编程风格的意义
?增加开发过程代码的强壮性、可读性、易维护性
?减少有经验和无经验开发人员编程所需的脑力工作
?为软件的良好维护性打下好的基础
?在项目范围内统一代码风格
?通过人为以及自动的方式对最终软件应用质量标准
?使新的开发人员快速适应项目氛围
?支持项目资源的复用：允许开发人员从一个项目区域（或子项目团队）移动到另一个，而不需要重新适应新的子项目团队的氛围
?一个优秀而且职业化的开发团队所必需的素质
1.2 变量命名的规则
①变量的命名规则要求用“匈牙利法则”。
即开头字母用变量的类型，其余部分用变量的英文意思或其英文意思的缩写,尽量避免用中文的拼音,要求单词的第一个字母应大写。即：变量名=变量类型+变量的英文意思（或缩写）
对非通用的变量，在定义时加入注释说明，变量定义尽量可能放在函数的开始处。
见下表：
bool(BOOL) 用b开头bIsParent
byte(BYTE) 用by开头byFlag
short(int) 用n开头nStepCount
long(LONG) 用l开头lSum
char(CHAR) 用c开头cCount
float(FLOA T) 用f开头fA vg
double(DOUBLE) 用d开头dDeta
void(VOID) 用v开头vV ariant
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_+变量类型+变量的英文意思（或缩写）
④、静态变量用s_开头,如一个静态的指针变量定义为s_plPerv_Inst,即：变量名=s_+变量类型+变量的英文意思（或缩写）
⑤、成员变量用m_开头,如一个长型成员变量定义为m_lCount;即：变量名=m_+变量类型+变量的英文意思（或缩写）
⑥、对枚举类型（enum）中的变量，要求用枚举变量或其缩写做前缀。并且要求用大写。
如：enum cmEMDAYS
{
EMDAYS_MONDAY;
EMDAYS_TUESDAY;
……
};
⑦、对struct、union、class变量的命名要求定义的类型用大写。并要加上前缀，其内部变量的命名规则与变量命名规则一致。
结构一般用S开头
如：struct ScmNPoint
{
int nX;//点的X位置
int nY; //点的Y位置
};
联合体一般用U开头
如: union UcmLPoint
{
long lX;
long lY;
}
类一般用C开头
如：
class CcmFPoint
{
public:
float fPoint;
};
对一般的结构应该定义为类模板，为以后的扩展性考虑
如：
template
class CcmTV ector3d
{
public:
TYPE x,y,z;
};
⑧、对常量（包括错误的编码）命名，要求常量名用大写，常量名用英文表达其意思。如：#define CM_FILE_NOT_FOUND CMMAKEHR(0X20B) 其中CM表示类别。
⑨、对const 的变量要求在变量的命名规则前加入c_,即：c_+变量命名规则；例如：const char* c_szFileName;
1.3 函数的命名规范
函数的命名应该尽量用英文表达出函数完成的功能。遵循动宾结构的命名法则，函数名中动词在前,并在命名前加入函数的前缀，函数名的长度不得少于8个字母。
例如：
long cmGetDeviceCount(……);
1.4 函数参数规范
①、参数名称的命名参照变量命名规范。
②、为了提高程序的运行效率，减少参数占用的堆栈，传递大结构的参数，一律采用指针或引用方式传递。
③、为了便于其他程序员识别某个指针参数是入口参数还是出口参数，同时便于编译器检查错误，应该在入口参数前加入const标志。如：
…cmCopyS tring(const char * c_szSource, char * szDest)
1.5 引出函数规范
对于从动态库引出作为二次开发函数公开的函数，为了能与其他函数以及Windows的函数区分，采用类别前缀+基本命名规则的方法命名。例如：在对动态库中引出的一个图象编辑的函数定义为imgFunctionname(其中img为image缩写)。
现给出三种库的命名前缀：
①、对通用函数库，采用cm为前缀。
②、对三维函数库，采用vr为前缀。
③、对图象函数库，采用img为前缀。
④、对宏定义，结果代码用同样的前缀。
1.6注释规范
1）、函数头的注释
对于函数，应该从“功能”，“参数”，“返回值”、“主要思路”、“调用方法”、“日期”六个方面用如下格式注释：
//程序说明开始
//================================================================//
// 功能：从一个String 中删除另一个String。
// 参数：strByDelete,strToDelete
// （入口）strByDelete: 被删除的字符串（原来的字符串）
// （出口）strToDelete: 要从上个字符串中删除的字符串。
// 返回：找到并删除返回1，否则返回0。（对返回值有错误编码的要// 求列出错误编码）。
// 主要思路：本算法主要采用循环比较的方法来从strByDelete中找到
// 与strToDelete相匹配的字符串，对多匹配strByDelete
// 中有多个strToDelete子串）的情况没有处理。请参阅：
// 书名......
//================================================================//
函数名(……)
//程序说明结束
①、对于某些函数，其部分参数为传入值，而部分参数为传出值，所以对参数要详细说明该参数是入口参数，还是出口参数，对于某些意义不明确的参数还要做详细说明（例如：以角度作为参数时，要说明该角度参数是以弧度（PI）,还是以度为单位）,对既是入口又是出口的变量应该在入口和出口处同时标明。等等。
②、函数的注释应该放置在函数的头文件中，在实现文件中的该函数的实现部分应该同时放置该注释。
③、在注释中应该详细说明函数的主要实现思路、特别要注明自己的一些想法，如果有必要则应该写明对想法产生的来由。对一些模仿的函数应该注释上函数的出处。
④、在注释中详细注明函数的适当调用方法，对于返回值的处理方法等。在注释中要强调调用时的危险方面，可能出错的地方。
⑤、对日期的注释要求记录从开始写函数到结束函数的测试之间的日期。
⑥、对函数注释开始到函数命名之间应该有一组用来标识的特殊字符串。
如果算法比较复杂，或算法中的变量定义与位置有关，则要求对变量的定义进行图解。对难以理解的算法能图解尽量图解。
2）、变量的注释：
对于变量的注释紧跟在变量的后面说明变量的作用。原则上对于每个变量应该注释，但对于意义非常明显的变量，如：i,j等循环变量可以不注释。
例如：long lLineCount //线的根数。
3）、文件的注释：
文件应该在文件开头加入以下注释：
/////////////////////////////////////////////////////////////////////
// 工程: 文件所在的项目名。
// 作者：**，修改者：**
// 描述:说明文件的功能。
// 主要函数：…………
// 版本: 说明文件的版本，完成日期。
// 修改: 说明对文件的修改内容、修改原因以及修改日期。
// 参考文献：......
/////////////////////////////////////////////////////////////////////
为了头文件被重复包含要求对头文件进行定义如下:
#ifndef __FILENAME_H__
#define __FILENAME_H__
其中FILENAME为头文件的名字。
4、其他注释：
在函数内我们不需要注释每一行语句。但必须在各功能模块的每一主要部分之前添加块注释，注释每一组语句，在循环、流程的各分支等，尽可能多加以注释。
其中的循环、条件、选择等位置必须注释。
对于前后顺序不能颠倒的情况，建议在注释中增加序号。
2 代码组织
代码组织是对整个项目的代码进行整理，使之更加有序。实现类似功能的文件应该放在同一个文件夹中或者同一个项目中。
1）、尽量用树形结构组织模块，即尽量保证单级调用关系，即上级调用者不要使用下级调用的模块中的函数、变量，不要有跨级调用关系，更不要有循环调用关系，可以有自身的递归调用关系。
2）、给每个.c文件建立一个.h文件，在其中声明所定义的全部函数（可以省略extern修饰）和全部内部变量，确保用extern修饰，确保.c文件中有对应的变量定义，确保.c文件的变量定义之前就#include "filename.h"。
3）、对于模块中用到了其它模块的变量或者函数，要在.c文件中的变量定义之前追加对应的模块头文件#include "externalfilename.h"；同时指示链接器（linker）链接相应模块编译后的.o文件，不然只能通过compiling阶段，在linking阶段报告找不到汇编级函数入口的错误和定义前使用变量的违例。
4）、代码整合时，在相应的项目文件中（makefile），用本模块的.c文件+ 被包含的其它模块的.h文件（或者只是用全部包含的.h文件）来表达模块依赖关系，用.c文件来表达编译对象。
5）、对于确实要在调用树中的多级使用到的模块，根据调用者的分布，尽量归为少数几个模块库（用一个.h+.c文件容纳），便于日后检查调用关系图。对于比较复杂的跨级调用关系，要在被调用的库模块的.h文件中加入#define LIB_THIS_FILENAME_H，同时在调用者的.c 文件中使用conditional directive：#ifndef LIB_INVOKEE_FILENAME_H #include "LIB_INVOKEE_FILENAME_H" #endif 这样形式来避免重复包含带来的“re-declaration”错误。
6）、设计可以从编写makefile文件开始，勾画出模块框架、模块功能分配表和调用关系图，并且touch 所需要到的.h文件和.c文件。然后在.h文件按照既定功能“列出”（实际是声明）所有变量和函数，并且在.c文件中编写相应的“空壳(nut)”。最后在.c文件头部填写相应的.h文件“列表”，表达调用关系。
7）、编写时的第一要点是保证模块的.c文件和.h文件同步更新，修改时先从.h文件开始。也可以从.c文件开始，然后利用工具重新生成.h文件。
8）、调试功能原型时，对于一些可能要用到辅助信息的检查，例如多个实现版本的对比，基于ADT的算法调试，一律采用#ifdef DEBUG #endif 限定起来，并且输出设备指向stdout。9）、对于那些即使在最终确认的程序中仍然可能要检查的信息，比如关键数据结构的状态历史，关键的流程转移标记，一律指向stderr输出，在需要时可以查看stderr端口检查。10）、在主函数或者核心函数的文件第一行加入#define DEBUG指示，在项目makefile中或者测试脚本中使用sed -i "1/s/#define DEBUG/\/\* #define DEBUG \*\//" MAIN_FILENAME.c 生成程序的最终版本。如果stderr输出影响性能，也可以通过sed去除所有的stderr的输出：sed -i "/s/fprintf(stderr\(*\)$/\/\* fprintf(stderr\(1\)/" *.c
3 代码优化
3.1 代码优化的意义
?仅仅对符合功能说明书的要求、能正确运行的代码进行优化是有意义的
?代码优化能减少冗余代码的数量，用更少的代码来实现同样的功能
?提高代码的内聚程度，减少耦合程度
对代码的抽象能提高代码的重用度，对今后其他项目的进度有非常重要的意义
3.2代码优化的方法
1）选择一个更好的算法
应该熟悉算法语言,知道各种算法的优缺点,一般很多计算机资料文本上有介绍,应该能够看得懂算法描述。
还要选择一种合适的数据结构(记着,你的程序所干的唯一一件事就是在计算机里搬数,把一堆数从一个地方提出来,处理一下,甩到另一个地方,那么按什么方式搬数有多重要你应该知道了吧--东楼),比如你在一堆随机存放的数中使用了大量的插入和删除指令,那使用链表要
快得多.如果你要做二分法查找,那提前排下序非常重要。
2）写一些清晰,可读性好并且简单的代码
3）透视你的程序
一个程序写出来,凭直觉就应该感觉出哪些地方快,哪些地方慢,一般说来,最快的运算就是分配一块内存,给指针赋值,还有就是两个整数的加法运算,别的都有点慢,最慢的就要数打开文件,打开新的进程,读写一大块内存,寻找,排序等等
4）理解你的编译程序选项
许多编译程序有几级优化选项,注意使用最优化的一项,特别注意gcc,优化选项非常多,小心使用,别弄得适得其反。
5）内联(内嵌)
gcc(使用-finline-functions参数),还有一些别的编译器可以在最高级优化中内联一些小的函数.K&C编译器则只有在库函数是用汇编写成的时候才内联,C++编译器普遍支持内联函数. 不过把C函数写成宏也能达到加速的作用,不过必须是在程序完全除错之后,因为绝大多数除错程序不支持宏除错。
4 调试技巧
4.1静态检查
先进行人工检查，即静态检查。
在写好一个程序以后，不要匆匆忙忙上机，而应对程序进行人工检查。这一步十分重要，它能发现程序设计人员由于疏忽而造成的多数错误。这一步往往容易被人忽视，总希望把一切都推给计算机去做，但这样会多占用机器时间，作为一个程序人员应当养成严谨的作风，每一步都要严格把关，不把问题留给后面的工序。
为了更有效地进行人工检查，所编的程序应力求做到以下几点：
①应当采用结构化程序方法编程，以增加可读性；
②尽可能多加注释，以帮助理解每段程序的作用；
③在编写复杂的程序时不要将全部语句都写在main函数中，而要多利用函数，用一个函数来实现一个单独的功能。各函数之间除用参数传递数据外，尽量少出现耦合关系，这样便于分别检查和处理。
4.2 上机调试
上机调试即动态调试，通过上机发现错误称为动态检查。在编译时会给出语法错误的信息，调试时可以根据提示信息具体找出程序中出错之处并改正。应当注意的是有时提示出错的地方并不是真正出错的位置，如果在提示出错的行找不到错误的话应当到上一行再找。有时提示出错的类型并非绝对准确，由于出错的情况繁多且各种错误互有关联，因此要善于分析，找出真正的错误，而不要只从字面意义上找出错信息，钻牛角尖。
如果系统提示的出错信息很多，应当从上到下逐一改正。有时显示出一大片出错信息往往使人感到问题严重，无从下手。其实可能只有一二个错误。例如，对使用的变量未定义，编译时就会对所有含该变量的语句发出出错信息。这时只要加上一个变量定义，就所有错误
都消除了
4.3 C语言常见问题
运行结果不对，大多属于逻辑错误。对这类错误往往需要仔细检查和分析才能发现。可以采用以下办法：
1.将程序与流程图仔细对照，如果流程图是正确的，程序写错了，是很容易发现的。例如，复合语句忘记写花括弧，只要一对照流程图就能很快发现。
2.如果实在找不到错误，可以采用“分段检查”的方法。在程序不同的位置设几个printf 函数语句，输出有关变量的值，逐段往下检查。直到找到在某一段中数据不对为止。这时就已经把错误局限在这一段中了。不断减小“查错区”，就能发现错误所在。
3.也可以用“条件编译”命令进行程序调试（在程序调试阶段，若干printf函数语句就要进行编译并执行。当调试完毕，这些语句不用再编译了，也不再被执行了）。这种方法可以不必一一去掉printf函数语句，以提高效率。
4.如果在程序中没有发现问题，就要检查流程图有无错误，即算法有无问题。如有则改正之，接着修改程序。
5.有的系统还提供debug（调试）工具，跟踪程序并给出相应信息，使用更为方便，请查阅有关手册。
总之，程序调试是一项细致深入的工作，需要下功夫，动脑子，善于积累经验。在程序调试过程中往往反映出一个人的水平，经验和态度。希望大家给以足够的重视。上机调试程序的目的决不是为了“验证程序的正确”，而是“掌握调试的方法和技术”，要学会自己找问题，这样慢慢自己就会写出错误较少的实用程序。
程序设计综合训练<图书馆管理系统> 设计报告 院系：材料科学与工程学院 专业班级：材料成型一班 姓名：张成智 学号： 20111402128 指导老师：肖老师
一、程序功能简介 图书排序功能 1）按图书编号排序 可以按图书编号的大小排序，显示到屏幕上。（从小到大） 2）按图书出版时间排序 可以按图书出版时间的前后排序，显示到屏幕上。（从近到远） 3）按图书价格排序 可以按图书价格的贵宜排序，显示到屏幕上。（从便宜到贵） 4）按图书书名排序 可以按图书书名字符的大小排序，显示到屏幕上。（从小到大） 5）按图书作者名排序 可以按图书作者名字符的大小排序，显示到屏幕上。（从小到大） 二、本人完成的主要工作 图书排序功能（排序比较简单只要做出来一个，其他都和它雷同。） 三、设计方案 1.设计分析； 1)序功能简介： s 进入系统
|| 2）各个功能流程图 1、按图书编号排序 菜单 1-添加图书 4-图书排序 5-查询图书 6-修改图书 7-录入数据 0-退出系统 2-删除图书 3-图书列表 输入编号、书名、 作者名、出版社、 类别、出版时间、 价格。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行删除。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行列出。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行排列。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行咨询。 依次录入编号、书名、作者名、出版社、类别、出版时间、 选择编号、书名、作者名、出版社、类别、出版时间、 价格进行修改。 输入0返回原始菜单。
知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了Google Java Style，包括了其他一些业界约定俗成的公约和普遍采用的标准。本规范并非最终标准，一些规定还需再做商讨。 1.1 术语说明 本文档除非特殊说明，否则： 1. 类（class）统指普通类、枚举类、接口和注解类型。 2. 注释（comment）只用来指实现注释（implementation comments）。我们不使用“文 档注释”这样的说法，而会直接说Javadoc。 其他“术语说明”，将在文档中需要说明的地方单独说明。 1.2 文档说明 本文档中的代码并不一定符合所有规范。即使这些代码遵循本规范，但这不是唯一的代码方式。例子中可选的格式风格也不应该作为强制执行的规范。
二、源码文件基础 2.1 文件名 源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。 2.2 文件编码：UTF-8 源码文件使用UTF-8编码。 2.3 特殊字符 2.3.1 空格字符 除了换行符外，ASCII 水平空白字符（0x20）是源码文件中唯一支持的空格字符。这意味着： 1. 其他空白字符将被转义。 2. Tab字符不被用作缩进控制。 2.3.2 特殊转义字符串 任何需要转义字符串表示的字符（例如\b, \t, \n, \f, \r, \", \'和\\等），采用这种转义字符串的方式表示，而不采用对应字符的八进制数（例如\012）或Unicode 码（例如\u000a）表示。 2.3.3 非ASCII 字符 对于其余非ASCII字符，直接使用Unicode字符（例如∞），或者对应的Unicode 码（例如\u221e）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。
程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在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:
WEB前端代码规范 规范目的 为提高团队协作效率，便于后台人员添加功能及前端后期优化维护，输出高质量的文档，特制订此文档。本规范文档一经确认，前端开发人员必须按本文档规范进行前台页面开发。本文档如有不对或者不合适的地方请及时提出，经讨论决定后方可更改。 基本准则 符合web标准；语义化html；结构、表现、行为分离；兼容性优良。页面性能方面，代码要求简洁明了有序，尽可能的减小服务器负载，保证最快的解析速度。 文件规范
3.jsp文件命名：英文驼峰式命名，文件名.jsp。按实际模块需求命名。 4.css文件命名：英文驼峰式命名，文件名.css。共用base.css，首页index.css，其他 页面按实际模块需求命名。 5.js文件命名：英文驼峰式命名，文件名.js。共用common.js，其他依实际模块需求命 名。 html书写规范 1.文档类型声明及编码：统一为html5的声明类型；编码统一为 ，书写时利用IDE实现层次分明的缩进。 2.非特殊情况下css文件必须在
...之间引入，选择link方式引入而非 @import形式。 3.非特殊情况下js文件必须在页面底部引入。 4.引入样式文件或JavaScript文件时，须略去默认类型声明，写法如下：11.语义化html，如标题根据重要性用h1-h6(同一页面只能有一个h1)，段落标记用p，列表 用ul，内联元素中不可嵌套块状元素。 12.尽可能减少div的嵌套层数。 13.在页面中尽量避免使用内嵌样式表，即在标签内使用style="…"。 14.以背景形式呈现的图片，尽量写入css样式中；重要图片必须加上alt属性； 15.特殊符号使用：尽可能使用代码替代：比如<(<)、>(>)、空格( )、&(&)、 ”（"）等等； 16.尽量避免使用过度复杂的HTML结构。 css书写规范 1.编码统一为utf-8。 2.为了避免一些浏览器兼容性问题以及增加样式重用性，每个页面必须引入base.css（详见 附件一），此文件不可随意修改。 3.class与id的使用：id是唯一的并是父级的，class是可以重复的并是子级的，所以id 仅使用在大的模块上，class可用在重复使用率高及子级中。 4.为JavaScript预留钩子的命名，请以js_起始，比如：js_hide，js_show。 5.class与id命名：使用英文命名，命名要语义化，简明化，但不要使用诸如first，last 之类的命名。使用驼峰式和下划线分隔相结合的命名规则，即命名应以父级加子级的命名规范，如：父级的类为simple 子级的类应该为simple_first，以此类推，但是尽量避免出现超过四级的类命名。 6.css属性书写顺序，建议遵循：自身属性-->布局定位属性-->文本属性-->其他属性。此条 可根据自身习惯书写，但尽量保证同类属性写在一起。
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最重要的部分。
百度文库- 让每个人平等地提升自我 1 程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* (C), MicTiVo International. Co., Ltd. 1.File : . History: Date: Author: Modification: 2. .. *************************************************/ 一、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************ (C), MicTiVo International. Co., Ltd. FileName: Author: Version : Date: : / /*receive _process() */ 意:与溢出中断写初值不同}
QC 质量管理体系文件 代码编写规范 受控状态：■受控□非受控 发布日期：2006年02月20日 实施日期：2006年02月24日
1. 引言 1.1. 目的 制定本规范是为了能达到以下目的： ●提高程序员工作效率和代码的利用性 ●程序员可以了解任何代码，弄清程序的状况 ●新人可以很快的适应环境 ●防止新接触php的人出于节省时间的需要，自创一套风格并养成终生的习惯 ●防止新接触php的人一次次的犯同样的错误 ●在一致的环境下，人们可以减少犯错的机会 1.2. 适用范围 适用于本公司的所有开发人员，包括数据库、网页及应用程序开发人员，及有关的程序测试人员。 1.3. 引用标准 GB/T 8566-1995 信息技术软件生存期过程 GB/T 8567-1988 计算机软件产品开发文件编写指南 1.4. 术语 GB/T 11457-1995中所使用的术语适用于本规范。
2. 代码编写规则 2.1. 注释 （1）编写代码期间注释要求占程序总量15%以上。 （2）每个模块顶部必须说明模块名称、功能描述、作者等。 （3）每个过程、函数、方法等开头部分必须说明功能、参数、返回值、原数据和目标数据数据结构等等。 （4）变量定义的行末应当对变量给出注释。 （5）程序在实现关键算法的地方应当给出注释 2.2. 变量、函数、过程、控件等命名规则 （1）变量命名采用[作用范围][数据类型][自定义名称]规则定义，要求看到变量名就能直观的看出其范围和数据类型。 （2）函数、过程、方法、事件等命名应尽量做到观其名知其义。 （3）控件的命名采用[控件类型][自定义名]规则定义,要求通过名字能直观看出控件类型。 （4）自定义命名空间规则，要求能顾名思义 2.3. 源代码规则 风格约定：采用缩进的格式保存程序的层次结构。要求能直观的看出循环、判断等层次结构。
Web前端开发规范 参考手册 一、规范目的 1.1 概述 为提高团队协作效率，便于后台人员添加功能，及前端后期优化维护，输出高质量的文档，特制订此文档。本规范文档一经确认，前端开发人员必须按本文档规范进行前台页面开发。本文档如有不对或者不合适的地方请及时提出，经讨论决定后可以更改。 1.2 基本准则 符合web标准，语义化HTML，结构表现行为分离，兼容性优良。页面性能方面，代码要求简洁明了有序，尽可能的减小服务器负载，保证最快的解析速度。 二、规范细则 2.1 文件命名规则 文件名称统一用小写的英文字母、数字和下划线的组合，其中不得包含汉字、空格和特殊字符。命名原则的指导思想： ●一是使得工作组的每一个成员能够方便的理解每一个文件的意义。 ●二是当在文件夹中使用“按名称排例”的命令时，同一种大类的文件能够排列在一 起，以便查找、修改、替换、计算负载量等等操作。 1. HTML命名原则 ●引导文件统一使用index.htm、index.html、ndex.asp文件名（小写）。 ●各子页命名的原则首先应该以栏目名的英语翻译取单一单词为名称。例如： ?关于我们\ aboutus ?信息反馈\ feedback ?产品\ product ●如果栏目名称多而复杂并不好以英文单词命名，则统一使用该栏目名称拼音或拼音 的首字母表示；每一个目录中应该包含一个缺省的html 文件，文件名统一用 index.htm、index.html、index.asp。
2. 图片命名原则 ●图片的名称分为头尾两部分，用下划线隔开，头部分表示此图片的大类性质。例如： 广告、标志、菜单、按钮等。 ●放置在页面顶部的广告、装饰图案等长方形的图片取名：banner。 ●标志性的图片取名：logo。 ●在页面上位置不固定并且带有链接的小图片取名：button 。 ●在页面上某一个位置连续出现，性质相同的链接栏目的图片取名：menu。 ●装饰用的照片取名：pic。 ●不带链接表示标题的图片取名：title。 例如： banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg ●鼠标感应效果图片命名规范为"图片名+_+on/off"。 例如： menu1_on.gif menu1_off.gif 3. Javascript命名原则 例如： ●广告条的javascript文件名为ad.js ●弹出窗口的javascript文件名为pop.js 4. 动态语言文件命名原则 以性质_描述，描述可以有多个单词，用“_”隔开，性质一般是该页面得概要。例如：register_form.asp register_post.asp topic_lock.asp 2.2 文件存放位置规范 HTML、CSS、js、images文件均归档至<系统开发规范>约定的目录中。 _Root cn 存放中文HTML文件 en 存放英文HTML文件 flash 存放Flash文件 images 存放图片文件 imagestudio 存放PSD源文件
程序代码注释编写规范 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. .. *************************************************/ 二、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************
Web前端开发规范手册 一、规范目的 1.1 概述 (1) 二、文件规范 2.1 文件命名规则 (1) 2.2 文件存放位置 (2) 2.3 css 书写规范 (3) 2.4 html书写规范 (7) 2.5 JavaScript书写规范 (11) 2.6 图片规范 (12) 2.7 注释规范 (13) 2.8 css 浏览器兼容 (13) 一、规范目的 1.1 概述 为提高团队协作效率, 便于后台人员添加功能及前端后期优化维护, 输出高质量的文档, 特制订此文档. 本规范文档一经确认, 前端开发人员必须按本文档规范进行前台页面开发. 本文档如有不对或者不合适的地方请及时提出, 经讨论决定后可以更改此文档. 二、文件规范 2.1 文件命名规则 文件名称统一用小写的英文字母、数字和下划线的组合，其中不得包含汉字、空格和特殊字符；命名原则的指导思想一是使得你自己和工作组的每一个成员能够方便的理解每一个文件的意义，二是当我们在文件夹中使用“按名称排例”的命令时，同一种大类的文件能够排列在一起，以便我们查找、修改、替换、计算负载量等等操作。
a. HTML的命名原则 引文件统一使用index.htm index.html index.asp文件名（小写） 各子页命名的原则首先应该以栏目名的英语翻译取单一单词为名称。例如： 关于我们\ aboutus 信息反馈\ feedback 产品\ product 如果栏目名称多而复杂并不好以英文单词命名，则统一使用该栏目名称拼音或拼音的首字母表示； 每一个目录中应该包含一个缺省的html 文件，文件名统一用index.htm index.html index.asp； b. 图片的命名原则 图片的名称分为头尾两部分，用下划线隔开，头部分表示此图片的大类性质 例如：广告、标志、菜单、按钮等等。 放置在页面顶部的广告、装饰图案等长方形的图片取名：banner 标志性的图片取名为：logo 在页面上位置不固定并且带有链接的小图片我们取名为button 在页面上某一个位置连续出现，性质相同的链接栏目的图片我们取名：menu 装饰用的照片我们取名：pic 不带链接表示标题的图片我们取名：title 范例：banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg 鼠标感应效果图片命名规范为"图片名+_+on/off"。 例如：menu1_on.gif menu1_off.gif c. javascript的命名原则 例如：广告条的javascript文件名为ad.js 弹出窗口的javascript文件名为pop.js d. 动态语言文件命名原则 以性质_描述，描述可以有多个单词，用“_”隔开，性质一般是该页面得概要。 范例：register_form.asp register_post.asp topic_lock.asp 2.2 文件存放位置规范 _Root cn 存放中文HTML文件 en 存放英文HTML文件 flash 存放Flash文件 images 存放图片文件 imagestudio 存放PSD源文件 flashstudio 存放flash源文件 inc 存放include文件 library 存放DW库文件 media 存放多媒体文件 project 存放工程项目资料
命名规范： 1.所有的标识都只能使用ASCII字母（A-Z或a-z）、数字（0-9）和 下划线”_”。 2.一个唯一包名的前缀总是用全部小写的字母。 3.类名是一个名词，采用大小写混合的方式，每个单词的首字母大 写。 4.接口的大小写规则与类名相似。 5.方法名是一个动词或是动词词组，采用大小写混合的方式，第一 个单词的首字母小写，其后单词的首字母大写。 6.变量名的第一个字母小写，任何中间单词的首字母大写，变量名 应简短且可以顾名思义，易于记忆。避免单个字符的变量名，除非是一次性的临时变量。 7.常量的声明应该全部大写，每个单词之间用”_”连接。 注释规范： 1.注释尽可能使用”//”,对于所有的Javadoc的注释使用/***/，而 临时对代码块进行注释应尽量使用/**/。 2.所有的源文件都应该在开头有一个注释，其中列出文件名、日期 和类的功能概述。每个方法必须添加文档注释（main除外）。 3.每个属性必须加注释。 4.代码中至少包含15%的注释。 5.注释使用中文。
缩进排版规范： 1.避免一行的长度超过60个字符。 2.使用Eclipse源代码的格式化功能完成代码的缩进排版。 文件名规范： 1.一个Java源文件只能储存一个Java类。 2.文件名与Java类相同。 3.一个类文件不超过200行。 声明规范： 1.一行声明一个变量。 2.不要将不同类型变量的声明放在同一行。 3.只在代块的开始处声明变量。 4.所有的变量必须在声明时初始化。 5.避免声明的局部变量覆盖上一级声明的变量。 6.方法与方法直接以空行分隔。 语句规范： 1.每行至少包含一条简单语句。 2.在return语句中，返回值不使用小括号”()”括起来。 3.If月总是用{和}括起来。 4.在for语句的初始化或者更新子句中，避免因使用3个以上变量， 而导致复杂度提高。 5.当switch的一个case顺着往下执行时（因为没有break），通常 应在break语句的位置添加注释。
Web前端开发规范手册 修订历史记录 日期版本说明作者 2012年12月31日 1.0初稿施昀 2012年01月05日 1.1施昀、戴静2012年01月07日 1.2施昀 目录 修订历史记录 (1) 一、规范目的 (2) 1.1概述 (2) 二、基本准则 (2) 三、文件规范 (3) 2.1文件命名规则 (3) 2.1.1HTML的命名原则 (3) 2.1.2图片的命名原则 (3) 2.1.3.javascript的命名原则 (4) 2.1.4动态语言文件命名原则 (4) 2.2文件存放位置规范 (4) 2.3CSS书写规范 (4) 2.3.1基本原则 (4)
2.3.2注意细则 (5) 2.3.3命名规则 (6) 2.4html书写规范 (9) 2.4.1head区代码规范 (9) 2.4.2body区代码规范 (10) 2.5JavaScript书写规范 (10) 2.6图片规范 (10) 2.7注释规范 (11) 2.7.1html注释 (11) 2.7.2css注释 (11) 2.7.3JavaScript注释 (11) 四、执行模式 (12) 一、规范目的 1.1概述 提高团队协作效率 便于前端开发以及后期优化维护 方便新进的成员快速上手 输出高质量的代码 本规范文档一经确认,前端开发人员必须按本文档规范进行前台页面开发。本文档如有不对或者不合适的地方请及时提出，经讨论决定后可以更新此文档。 二、基本准则 符合web标准,语义化html,结构表现行为分离,兼容性优良。 代码要求简洁明了有序,尽可能的减小服务器负载,保证最快的解析速度。
开发时需要遵循如上基本准则，特殊情况可以有所宽限，如一些老项目的页面改造。 三、文件规范 2.1文件命名规则 [使用场景：在新建网页、图片、脚本、CSS文件时，根据此规则给文件命名并放入指定位置] 文件名称统一用小写的英文字母、数字和下划线的组合，其中不得包含汉字空格和特殊字符。命名原则的指导思想一是使得你自己和工作组的每一个成员能够方便的理解每一个文件的意义，二是当我们在文件夹中使用“按名称排例”的命令时，同一种大类的文件能够排列在一起，以便我们查找、修改、替换、计算负载量等等操作。 2.1.1HTML的命名原则 索引文件统一使用index.htm index.html index.asp文件名。 如果栏目名称多而复杂并不好以英文单词命名，则统一使用该栏目名称拼音或拼音的首字母表示。 每一个目录中应该包含一个缺省的html文件，文件名统一用index.htm index.html index.asp。 2.1.2图片的命名原则 图片的名称分为头尾两部分，用下划线隔开，头部分表示此图片的大类性质。 例如：广告、标志、菜单、按钮等等。 放置在页面顶部的广告、装饰图案等长方形的图片取名：banner 标志性的图片取名为：logo 在页面上位置不固定并且带有链接的小图片我们取名为button 在页面上某一个位置连续出现，性质相同的链接栏目的图片我们取名：menu 装饰用的照片我们取名：pic 不带链接表示标题的图片我们取名：title 范例：banner_sohu.gif banner_sina.gif menu_aboutus.gif menu_job.gif title_news.gif logo_police.gif logo_national.gif pic_people.jpg
Delphi 6 程序员代码编写标准指南 一、序言 二、通用源代码格式规则 2.1 缩格 2.2 页边空格 2.3 Begin…End 配对 2.4 代码文件中通用符号含义 三、Object Pascal 3.1 括号 3.2 保留字和关键字 3.3 过程和函数（例程） 3.3.1 命名/格式化 3.3.2 形式参数 3.3.2.1 格式化 3.3.2.2 命名 3.3.2.3 参数的排序 3.3.2.4 常量参数 3.3.2.5 名称的冲突 3.4 变量 3.4.1 变量的命名和格式 3.4.2 局部变量 3.4.3 全局变量的使用 3.5 类型 3.5.1 大写约定 3.5.1.1 浮点指针类型 3.5.1.2 枚举类型 3.5.1.3 变数和ole变数类型 3.5.2 结构类型 3.5.2.1 数组类型 3.5.2.2 记录类型 3.6 语句 3.6.1 if 语句 3.6.2 case 语句 3.6.2.1 一般性话题 3.6.2.2 格式 3.6.3 while 语句 3.6.4 for 语句 3.6.5 repeat 语句
3.6.6 with 语句 3.6.6.1 一般话题 3.6.6.2 格式 3.7 结构异常处理 3.7.1 一般话题 3.7.2 try…finally的使用 3.7.3 try…except的使用 3.7.4 try…except…else的使用 3.8 类类型 3.8.1 命名和格式 3.8.2 域 3.8.2.1 命名/格式 3.8.2.2 可视化 3.8.3 方法 3.8.3.1 命名/格式 3.8.3.2 使用静态的方法 3.8.3.3 使用虚拟/动态的方法 3.8.3.4 使用抽象的方法 3.8.3.5 属性存取方法 3.8.4 属性 3.8. 4.1 命名/格式 3.8. 4.2 使用存取的方法 四、文件 4.1 工程文件 4.1.1 命名 4.2 窗体文件 4.2.1 命名 4.3 数据模板文件 4.3.1 命名 4.4 远端数据模板文件 4.4.1 命名 4.5 Unit文件 4.5.1 通用Unit结构 4.5.1.1 unit的名字 4.5.1.2 uses子句 4.5.1.3 interface部分 4.5.1.4 implementation部分 4.5.1.5 initialization部分 4.5.1.6 finalization部分 4.5.2 窗体单元
前端开发设计规范 目录 前端开发设计规范 (1) 一、HTML使用规范 (1) 1.1、页面文件命名规范 (1) 1.2、页面head部分书写规范 (1) 1.3、HTML元素开发规范 (2) 1.3.1、HTML元素书写规范 (2) 1.3.2、HTML元素命名规范 (4) 二、WEB页面开发规范 (5) 2.1、错误跳转页面的处理 (5) 2.2、提示信息的处理 (5) 2.3、页面的返回 (5) 2.4、提交前数据的判断验证 (5) 2.5、删除操作 (6) 2.6、页面中java代码的使用 (6) 2.7、网站页面布局规范 (7) 2.7.1、前台页面尺寸 (7)
2.7.2、标准网页广告图标规格（参考） (7) 2.7.3、页面字体 (8) 2.7.4、字体颜色 (8) 三、javaScript开发规范 (9) 3.1、javaScript文件命名规范： (9) 3.2、javaScript开发规范 (9) 3.2.1、javaScript书写规范 (9) 3.2.2、javaScript命名规范 (10) 四、css样式规范 (12) 4.1、css样式文件命名规范 (12) 4.1.1、通用样式文件命名规范： (12) 4.1.2、业务类样式文件命名规范 (13) 4.1.3、css样式文件命名须知 (13) 4.2、css样式文件存放目录规范 (13) 4.3、css样式定义规范 (14) 4.3.1、css样式内容顶部注释规范 (14) 4.3.2、css样式内容注释规范 (14) 4.3.3、css样式定义规范 (15) 4.3.4、css样式常用id的命名 (17) 4.3.5、css样式常用class的命名 (18)
安全代码编写规范 一、编写目的 为加强武汉楚烟信息技术有限公司在软件开发中的安全规范要求，减少应用上线后带来潜在的安全风险，特拟定安全代码编写规范。二、使用范围 本规范适用于武汉楚烟信息技术有限公司承建的各类开发类的软件类项目。 三、应用安全设计 在总体架构设计阶段，需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等），须在设计文档中予以详细说明。对于互联网应用，务必明确网络安全、应用安全、数据安全相关的安全防护手段。 在技术架构上，应采用表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户。 在部署架构上，应采用应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失。如软件产品具备有条件时，应优先采用加密数据传输方式（例如https协议）。 在外部接口设计方面，应采用最小接口暴露的原则，避免开发不必要的服务方法带来相关安全隐患，同时对于第三方接口，应共同商定第三方接入的身份认证方式和手段。
四、应用安全编码 4.1. 输入验证 对于用户输入项进行数据验证，除常见的数据格式、数据长度外，还需要对特殊的危险字符进行处理。特殊字符包括<> " ' % ( ) & + \ \' \"等 对于核心业务功能，除在客户端或浏览器进行数据验证外，还必须在服务器端对数据进行合法性检验，规避用户跳过客户端校验，直接将不合规的数据保存到应用中。 对于浏览器重定向地址的数据，需要进行验证核实，确认重定向地址是否在可信，并且需要对换行符（\r或\n）进行移除或者替换。 4.2. 数据输出 对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS)。对于无法规避的HTML片段提交，需对