代码审查规范
代码审查规范
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）
?代码是否符合制定的标准
?所有的变量都被正确定义和使用
?所有的注释都是准确的
?所有的程序调用都使用了正确的参数个数
3.4、可修改性检查（Modifiability）
?代码涉及到的常量是否易于修改(如使用配置、定义为类常量、使用专门的常量类等)
?代码中是否包含了交叉说明或数据字典，以描述程序是如何对变量和常量进行访问的
?代码是否只有一个出口和一个入口（严重的异常处理除外）
3.5、可预测性检查（Predictability）
?代码所用的开发语言是否具有定义良好的语法和语义
?是否代码避免了依赖于开发语言缺省提供的功能
?代码是否无意中陷入了死循环
?代码是否避免了无穷递归
3.6、健壮性检查（Robustness）
?代码是否采取措施避免运行时错误（如数组边界溢出、被零除、值越界、堆栈溢出等）
3.7、结构性检查（Structuredness）
?程序的每个功能是否都作为一个可辩识的代码块存在
?循环是否只有一个入口
3.8、可追溯性检查（Traceability）
?代码是否对每个程序进行了唯一标识
?是否有一个交叉引用的框架可以用来在代码和开发文档之间相互对应
?代码是否包括一个修订历史记录，记录中对代码的修改和原因都有记录
?是否所有的安全功能都有标识
3.9、可理解性检查（Understandability）
?注释是否足够清晰的描述每个子程序
?是否使用到不明确或不必要的复杂代码，它们是否被清楚的注释
?使用一些统一的格式化技巧（如缩进、空白等）用来增强代码的清晰度
?是否在定义命名规则时采用了便于记忆，反映类型等方法
?每个变量都定义了合法的取值范围
?代码中的算法是否符合开发文档中描述的数学模型
3.10、可验证性检查(Verifiability)
?代码中的实现技术是否便于测试
?测试代码是否正确，是否覆盖所有流程
4. Code Review的步骤
目前Code Review 步骤暂定如下，试行一段时间再根据问题做调整。
1.代码编写者和代码审核者坐在一起，由代码编写者按照设计文档中的用例
依次讲解自己所写的代码和相关逻辑，可采用从前端到后台的方式，例如从Web 层->DAO层。
2.代码审核者在此过程中可以随时提出自己的疑问，同时积极发现隐藏的bug；
代码编写者和代码审核者都要对这些bug记录在案，代码编写者修改后再次提交审核，代码审核者对应bug记录进行回验。
3.代码讲解完毕后，代码审核者给自己安排几个小时再对代码审核一遍。
代码需要一行一行静下心看。同时代码又要全面的看，以确保代码整体上设计优良。4.代码审核者根据审核的结果编写代码“审核结果”并将“审核记录”和“审核结
果”提交至GIT，审核记录和审核结果参见附录I 审核记录、附录II 审核结果。
5.代码编写者 GIT pull并根据“审核结果”给出的修改意见，修改好代码，有不清
楚的地方可积极向代码审核者提出。
6.代码编写者 bug fix等全部修改完成后提交代码审核者再次进行审核，通过审
核则代码审核者更新本次审查结果并提交至GIT，审核通过对代码不能再进行修改，任何已通过审核的代码修改必须重新进行审核流程。
7.代码审核者把Code Review中发现的有价值的问题更新到"代码规范"的文档
中，对于特别值得提醒的问题可群发email或QQ给所有技术人员。
5. Code Review 标准
代码审查的基础是我们的设计文档规范、代码规范、日志规范、测试代码规范，针对新增的业务场景和设计尚未有规范对应时应先确立规范然后再进行代码审核流程。
6. Code Review 注意点
6.1. 经常进行Code Review
?要Review的代码越多，那么要重构，重写的代码就会越多。而越不被代码编
写者接受的建议也会越多，唾沫口水战也会越多。建议每一个功能，每一个用例完成后都可以进行审核，将大任务拆分为小任务进行。
?程序员代码写得时候越长，程序员就会在代码中加入越来越多的个人的东西。?越接近软件发布的最终期限，代码也就不能改得太多。
6.2. Code Review不要太正式，而且要短
忘了那个代码评审的Checklist吧，走到你的同事座位跟前，像请师父一样请他坐到你的电脑面前，然后，花5分钟给他讲讲你的代码，给他另外一个5分钟让他给你的代码提提意见，这比什么都好。而如果你用了一个Checklist，让这个事情表现得很正式的话，下面两件事中必有一件事会发生：
?只有在Checklist上存在的东西才会被Review。
?Code Reviews 变成了一种礼节性的东西，你的同事会装做很关心你的代码，但其实他心里想着尽快地离开你。只有不正式的Code Review才会让你和评审者放轻松，人只有放松了，才会表现得很真实，很真诚。记住Review只不过是一
种形式，而只有在相互信任中通过相互的讨论得到了有意义和有建设性的建议和意见，那才是最实在的。不然，作者和评审者的关系就会变成小偷和警察的关系。
6.3. 尽可能的让不同的人Reivew你的代码
如果可能的话，不要总是只找一个人来Review你的代码，不同的人有不同的思考方式，
有不同的见解，所以，不同的人可以全面的从各个方面评论你的代码。但不要太多了，人多嘴杂反而适得其反，基本上来说，不要超过3个人，这是因为，这是一个可以围在一起讨论的最大人员尺寸。
下面是几个优点：
?从不同的方向评审代码总是好的。
?会有更多的人帮你在日后维护你的代码。
?这也是一个增加团队凝聚力的方法。
6.4. 保持积极的正面的态度
程序员最大的问题就是“自负”，尤其当我们Reivew别人的代码的时候，我已经见过无数的场面，程序员在Code Review的时候，开始抨击别人的代码，质疑别人的能力。
太可笑了，我分析了一下，这类的程序员其实并没有什么本事，因为他们指责对方的目的是想告诉大家自己有多么的牛，靠这种手段来表现自己的程序员，其实是就是传说中
所说的“半瓶水”。所以，无论是代码编写者，还是代码审核者，都需要一种积极向上
的正面的态度，编写者需要能够虚心接受别人的建议，因为别人的建议是为了让你做得更好；审核者也需要以一种积极的正面的态度向编写者提意见，因为那是和你在一个战壕里的战友。记住，你不是一段代码，你是一个人！
6.5. 学会享受Code Reivew
这可能是最重要的一个提示了，如果你到了一个人人都喜欢Code Reivew的团队，那
么，你会进入到一个生机勃勃的地方，在那里，每个人都能写出质量非常好的代码，在那里，你不需要经理的管理，团队会自适应一切变化，他们相互学习，相互帮助，不仅仅是写出好的代码，而且团队和其中的每个人都会自动进化，最关键的是，这个是一个团队。
7. Code Review操作
目前我们将Code Review 分为两个阶段，开发互审和上级审查两个阶段。
7.1 开发互审
任意两名开发人员（建议不要固定配对，避免思维定势）进行交叉代码审查，代码编写者准备所开发的代码相关的全部资料列表，包括需求、设计文档、代码工程、类、方法、配置文件、数据库修改、数据修改等全部资料的版本号等详细信息，向代码审查者全面介绍代码的目标和设计实现。代码审查者按照需求文档、设计文档、开发规范进行代码（业务、日志、测试）审查，代码审查者将审查结果提交至GIT，出现的问题由代码编写者进行修改并由代码审查者复审，复审结果提交至GIT保留。代码审查者对所审查的代码负责。
7.2 上级检查
开发互审完成后，由上级进行上级审查，流程与开发互审相同，对于三次复审仍未通过的代码需要代码编写者组内进行检讨问题原因，并书面列出改进计划。
7.3 冲突解决
当开发互审时对于检查内容出现争议时由上级进行协调解决或逐级向上协调解决。当上级审查时出现争议时逐级向上协调解决。
所有问题解决原则为公司利益、团队利益、业务需求、设计文档、规范
文档等为参考标准。
附录I 审核记录
审核记录如同修改记录一样，直接记录入代码头部，代码审核者修改审核记录后提交代码至GIT参考即可。之后的审核可以基于两次审核间的变更利用对比工具进行增量审核。可参考如下示例
类：ngp_common/src/main/java/com/heepay/file/FileUtils.java 代码示例：
附录II 审核结果
审核结果建议以表格的形式描述，每个问题分别列出，可以通过标注行号来具体指明位置，给出合理的修改意见并说明标准。为了方便记录和查询以及代码编写者修改和复审，
建议审核结果写入commit message中，由于commit message只能提交文本，我们以软表格的形式描述。对于commit message 的书写规范，查看参考。
格式：
示例：
docs(代码审核):审核失败
1.日志不符合规范问题：没有使用log4j2，日志不规范建议：修改使用log4j2，包括包引用和代码修改行号：53行
2.命名不符合规范问题：log命名不符合规范建议：修改为logger 行号：53行
C程序代码大全
//根据半径计算圆的周长和面积#include 项目开发规范文档修订历史记录 1.简介 目的 1、用于规范指导开发组进行开发 2、便于成员间的沟通与交流。 3、有助于项目质量和稳定。 4、为后期维护提供支持 2. 项目开发流程 项目开发过程归纳分为以下步骤： 1. 建立SVN项目版本控制。包括文档，源码，Lib包等。 2. 了解需求，并对需求文档的书写。(见文档结构规则附录)。 3. 详细设计文档。(见文档结构规则附录)。 功能模块设计，重要模块的算法设计。 数据库设计等。 根据需求定义开发平台及环境。 4. 编码。 搭建开发平台，配置开发环境。 编码。 单元测试案例。 5. 书写软件安装手册文件，数据库脚本文件，以及注意事项(release notes)。 6. 交互测试组测试。根据测试组测试结果是否回归第4步（测试回归最好不要超过2 次）。 7. 测试通过，交付上线使用。 维护手册 使用手册 3. 代码规范 Java 代码规范 3.1.1 Java类名 类名可由：英文字母，数字，下划线组成。（数字，下划线不能够开头） 类名由一个或者多个单词组成。单词通常要求简洁明了达意。能够通过类名能够大致了解此类的作用和用途。 类名要求首字母大写，多个单词组成类名时，单词的首字母要求大写。 建议：类名不要过于简单或者太长。可以对单词采用简化的名称：入： Number 简化为：num 。 3.1.2 Java类结构 类仅作为数据结构，没有行为，他封装了一组或者相似的一些行为方法。所以一个类尽量功能单一，或者功能类似共有行为的。一个类不要过于庞大。 通常情况下： 一般逻辑类中应该有构造方法和main方法，main方法中应该有测试代码。 每个类应该有 toString() 方法。 3.1.2.1 包和引入语句 在多数Java源文件中，第一个非注释行是包语句。在它之后可以跟引入语句。 报名的定义全部是小写字母。具体定义依据项目而定。 引入包时候，同一类型的归纳到一块，用空行隔开。例如： import 3.1.2 类注释 Java类开头应该有相应的注释：类版本描述，作者签名，日期时间，公司备注，类的功能作用相关描述等。（详细查看：注释） 3.1.2.2 类成员变量 a) 类变量要求放在类的开始声明。一行声明一个。 b) 变量名称首字母要求小写。其他命名规则类似与类名。 c) static , final 类型的变量，字母要求全部大写。 d) 尽量在声明局部变量的同时初始化。 e) 避免局部变量和成员变量同名，覆盖了成员变量。 f) 尽量变量私有化，缩小变量的作用域。 3.1.2.3 类成员方法 a) 方法名命名规则类似于成员变量命名规则。 b) 成员方法尽量私有化。 数控机床标准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 ------------------------------------------------------------------------摘自宋鲁生程序设计大赛 乘法口诀表 #include 用一维数组统计学生成绩 #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的所有操作都可以是本地的，仅仅在将新版本的内容上传到服务器上时才需要连接网络。 项目团队开发规范 修订历史记录 目录 1引言 (6) 1.1 编写目的 (6) 1.2 预期读者 (6) 1.3 编写背景 (6) 2概述 (7) 2.1 目标 (7) 2.2 修改及完善 (7) 3详细规范 (7) 3.1 使用的工具 (7) 3.2 框架设计 (7) 3.3 包目录 (8) 3.4 编码规范 (10) 3.4.1 目的 (10) 3.4.2 依据 (10) 3.4.3 具体规范 (10) 3.4.3.1 编码风格 (10) 3.4.3.1.1 缩进 (10) 3.4.3.1.2 空格 (11) 3.4.3.1.3 对齐 (12) 3.4.3.1.4 空行 (12) 3.4.3.1.5 代码长度 (13) 3.4.3.1.6 行数 (13) 3.4.3.1.7 注释 (14) 3.4.3.2 代码效率 (17) 3.4.3.2.1 综述 (17) 3.4.3.2.2 具体实现 (17) 3.4.3.3 异常处理 (17) 3.4.3.3.1 处理CHECK 异常与UNCHECK异常 (17) 3.4.3.4 程序调试 (17) 3.4.4 日常交流 (18) 3.4.4.1 互相促进 (18) 1引言 1.1 编写目的 本文档作为项目团队开发规范的说明书，描述了项目开发过程中的使用的工具，框架，代码编写规范及注意问题，作为项目团队建设，开发及测试工作的依据。 1.2 预期读者 本文档的预期读者包括以下几类： ?项目组长 ?项目组全体成员 1.3 编写背景 根据公司现有的开发状况，决定组件稳定的项目开发团队，制定全体团队成员共识的开发规范，有助于提高项目开发的效率、项目团队整体水平的提升。 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() 4J 代码规范 1性能级别规范 1.1对潜在的业务级异常捕获处理打印日志，参照spring源代码 1.2controller或service层需要数据校验，确保系统安全，具体在哪一层校验需确认 1.3业务处理代码只能出现于service层，确保事务安全与mvc结构清晰，如jsp，controller都不能有 1.4严禁循环中连接数据库，确保一次请求不产生过多的数据库连接 1.5使用sql直接进行统计查询等业务复杂度较低的操作，确保java代码的可读性与java内存性能 1.6业务复杂的操作会涉及到多次数据库连接，包括多表查询，更新等，这种情况尽量避免，可以将部分业务合并在一个sql中，或者使用存储过程 1.7sql语句避免直接使用“*”，除非在外层语句 1.8不允许单一的count语句使用orderby，limit，count(*) 1.9查询时分组、排序、条件、结果字段影响效率时，应该跟组长或DBA讨论是否需要建立索引 1.10Java代码不允许sql参数字符拼接方式，必须使用预编译方式（除非参数绝对不发生变化），确保数据安全与查询效率 1.11表间关联字段类型一致，确保索引不会失效 1.12mysql中没有函数索引，所以查询时尽量不要有索引列的函数，如substr(create_date, 1, 6) = substr('20110728', 1, 6) 实质是等于某月改写为 ——————————————————————————————————————————————————————————————— - 1 - create _date >=to_char(last_day(add_months(to_date('20110728','yyyymmdd'),-1)) + 1,'yyyymmdd')and create _date <= 该月最后一天 1.13编写sql时避免大表的全表扫描，尽量走索引，正确使用left join,right join,join对数据和效率影响 2代码基本规范 2.1数据库所有字段都为大写，单词之间用_分隔 2.2在所有JSP、JAVA代码中，如果是一个数据库字段对应的变量，则名称和数据库字段名称相同 2.3在JAVA、JSP中，除了与数据库字段对应的变量以外的所有变量，都以小写字母开头驼峰式命名，变量中各单词之间不要空格，不要有其它字母， 例如helloWorld 是正确的HelloWorld 、hello_world 这些都是错误的。 2.4代码提交到SVN时，在提交界面中，请写清修改的原因、事项 2.5在处理日期型的数据字段时，注意不要随意书写，要兼容ORACLE的写法 2.6在使用GROUP BY语句的时候，要注册兼容ORACLE的写法 2.7凡是牵扯到数据持久化的代码都要封装到dao层，切不可以在bean或者其他的层中写操作数据库的代码。 3代码书写原则 3.1JSP页面中，尽可能不写或者少写JAVA代码 3.2所有JS代码，都写在JSP页面的上方 3.3所有JSP代码、JS代码，都要写上完善的注释，因为这部分代码，会被经常改动。 4文件命名规范 ——————————————————————————————————————————————————————————————— - 2 - 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 前言 1.1 为什么需要开发规范 编码规范对于程序员而言尤为重要，有以下几个原因： * 一个软件的生命周期中，80%的花费在于维护 * 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护* 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码 * 如果你将源码作为产品发布，就需要确任它是否被很好的打包并且清晰无误，一如你已构建的其它任何产品 1.2 开发规范的作用 * 减少维护花费 * 提高可读性 * 加快工作交接 * 减少名字增生 * 降低缺陷引入的机会 2 命名规范 2.1 常量命名规范 2.1.1 类型 常量命名规范 2.1.2 说明 常量用于保存需要常驻内存中并且经常使用变化不多的数据，定义常量的名称的时候需要遵循望文知意的原则； 2.1.3 规则 1.全部为大写字母； 2.中间以“_”连接； 3.望文知意原则； 2.1.4 备注 代码中涉及到直接使用某个字符串或者其他基本类型的值时，建议定义成常量，避免多处直接使用同样的值作为参数。 2.1.5 举例 ?如：定义一个常量表示最小屏幕宽度的常量，则可以定义一个int类型的常 量，该常量可以命名为：“MIN_SCREEN_WIDTH“； ?其他举例： ?例如：static final int MIN_SCREEN_WIDTH = 4；( √) ?例如：static final int min_screen_width = 4;（×） ?例如：static final int minScreenWidth = 4; （×） ?例如：static final int WIDTH = 4；（×） 代码管理制度 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库中要求区别对待不同用户的可访问权、可读权、可写权。 1.程序版式 1.1.对齐 1.1.1.程序块要采用缩进风格编写，缩进的空格数为4个。使用VC提供的Tab 键对齐。 1.1. 2.“{”和“}”应独占一行并且位于同一列，同时引用他们的语句对齐1.1. 3.{}之内的代码块在“{”右边数格外左对齐 例： 正确错误 1.2.空行 1.2.1.每个声明之后，每个函数定义之后要加空行 1.2.2.在一个函数体内，逻辑上密切相关的语句之间不加空行，其它地方应加空 行分隔 1.2.3.变量声明和代码之间加空行 1.2.4.函数返回语句用空行 例： 1.3.代码行 1.3.1.一行代码只做一件事情，如只定义一个变量，或只写一条语句。 1.3. 2.if、for、do、while、case、switch、default等语句自占一行，且if、for、 do、while等语句的执行语句部分无论多少都要加括号{} 例： 示例：风格良好的代码行示例：风格不良的代码行 1.4.空格 1.4.1.关键字之后要留空格：const, virtual, inline, if, while, for 1.4. 2.函数名之后不要留空格 1.4.3.“（”向后紧跟“，”，“、”，“.”，“；”，“）”向前紧跟 1.4.4.“，”后要留空格，“”；之后如果不是一行的结束，后面要留空格 1.4.5.赋值操作符，比较，算术，逻辑，第二元操作符前后加空格 1.4.6.一元操作符！、~、++、--、—等前后不加空格 1.4.7.像[]、“.”、—＞等前后不加空格 例： 1.5.长行拆分 1.5.1.代码行最长度宜控制在70到80个字符以内，代码行不宜过长 1.5. 2.长表达式拆分，应将操作符放在新行之首，拆分出新行要适当缩进，使排 版整齐 例： 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，研发修改，再提交测试，然后预发布测试 HTML/CSS代码开发规范文档 目录 1、前言 (4) 2、HTML编码规范 (4) 2-1HTML标记的关闭规范 (4) 2-2HTML文件头基本标记 (4) 2-2HTML正文代码标记元素 (5) 2-3HTML标记的缩进规范 (6) 3、HTML文件引入CSS样式代码和Javascript代码规范 (6) 3-1引入css样式代码规范 (6) 3-2引入Javascript代码规范 (7) 4、HTML注释标签 (8) 5、CSS编码规范 (8) 5-1 CSS编码要求 (8) 5-2 CSS样式表规范 (8) 5-3 CSS命名规范 (9) 5-4样式文件命名 (10) 5-5样式文件布局 (11) 6、CSS常规书写规范及方法 (11) 6-1文件调用方法: (11) 6-2 CSS结构化书写 (11) 6.2.1派生选择器： (11) 6.2.2辅助图片用背影图处理： (12) 6.2.3结构与样式分离： (12) 6.2.4文档的结构化书写 (12) 6-3 HACK CSS书写规范 (13) 6.3.1 IE6、IE7、Firefox之间的兼容写法 (13) 6.3.2屏蔽IE浏览器 (14) 6.3.3清除浮动 (14) 6.3.4鼠标手势 (15) 7、CSS性代码缩写 (15) 7.1不同类有相同属性及属性值的缩写 (15) 7.2同一属性的缩写 (16) 7.3内外侧边框的缩写 (16) 7.4颜色值的缩写 (18) 8、CSS注释书规范 (18) 8.1行间注释 (18) 8.2整段注释 (18) 1、前言 本编程规范适用于需要编写HTML/CSS代码的网页程序开发人员。本规范并不是一个一成不变的必须严格遵守的条文，特殊情况下要灵活运用，做一定的变通。 2、HTML编码规范 HTML是一种标记语言, HTML没有任何真正的编程语言中的循环或是流程控制语句。然而，HTML代码的格式和风格是非常重要的，因为要经常对HTML代码进行维护和修改，因此HTML代码必须有很清晰的逻辑结构和布局,增强可读性，而使其易懂和易于维护。HTML代码本身是不区分大小写的，但是为了更好的统一代码布局，项目中HTML文件标记都以小写为主。 2-1HTML标记的关闭规范 HTML文档的正文都应在项目开发及编码规范
数控编程G、M、T、S代码大全(精选.)
C语言代码大全
Git源代码管理规范
java项目团队开发规范
C 经典程序代码大全
编码规范详细说明_v1详解
CNC加工中心程序代码大全
源代码管理规范
代码开发规范
源代码管理规范
开发管理之代码编码规范
代码版本管理规范_v1.1
HTML／CSS代码开发规范文档
…
等 和 2-2HTML文件头基本标记 ① ②