目录
一．规范简介
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
* @author 作者于时间
*/
（2）方法的注释
要求：遵循JavaDoc的规范，在每个方法的前部用块注释的方法描述此方法的作用，传入，传出参数的类型和作用，以及需要捕获的错误。
例如：
/**
* @Description: 方法描述
* @param menus 参数意义
* @return 返回值
* @throws AppException 错误描述
*/
（3）行注释
要求：使用//…的注释方法来注释需要表明的内容。并且把注释的内容放在需要注释的代码的前面一行或同一行。
（4）块注释
要求：使用/**和*/注释的方法来注释需要表明的内容。并且把注释的内容放在需要注释的代码的前面。
（5）行尾注释
要求：尽量不使用行尾注释。如需使用，必须与代码末端保持一个空格。
例子：return true; //注释内容//这是正确的写法。
反例：return true;//注释内容 //错误写法。不能借助模板格式化此处，需要代//码编写者自行注意。
（5）常用的javadoc文档标签有
@author,@throws,@param,@deprecated,@return,@link,@see,@since,@version等
2.1.3 修改缺陷注释
在修改bug时，要带bug号和简短说明时间和修改者，加上修改开始结束，避免发生修改覆盖的情况，导致bug的反复。
例子 :
//张三 2009-07-15 BUG-1388 修改开始修改判断状态
*****
*****
//张三2009-07-15 BUG-1388 修改结束
格式
2.2 源文件结构
一个文件由被空行分割而成的段落以及标识每个段落的可选注释共同组成。超过2000行的程序难以阅读，应该尽量避免。
Java源文件结构应该遵循下面的结构：
文件注释
包声明
导入声明
类注释
类声明
注意：
（1）导入多个类时，系统类放在上面，非系统类放在下面，中间以空行分开，按字母升序排列。
（2）在导入声明的时候，应避免使用通配符(如:import java.util.*)，而要用完整的导入声明(如:import java.util.Vector)。
这样做的好处是使后来阅读代码的人可以很清楚的知道这个程序中用到了那些类并且防止后来的人导入的类和你现在用的类有冲突，另外，编译器在有通配符的情况下，搜索会由额外的开销，消耗资源。
2.3 类结构
类的声明应该遵循下面的结构：
类变量声明及注释
实例变量声明及注释
类构造声明及注释
类方法声明及注释
实例方法声明及注释
2.4 命名
2.4.1 总体原则
（1）要求：必须用完整的有意义的英文名称，不要用拼音，尽量少用阿拉伯数字
例子：userID //正确，含义明确。
反例：yonghuID //反例1。使用拼音。
g //反例2。含义不明，代码阅读困难。
（2）要求：尽量采用相关领域的术语。
例子：accountName //正确。可以表示账户名。
反例：userName //在表示“账户名”时避免。表达尽量使用精确的，不容易产生歧义的术语。
（3）要求：尽量少用缩写，但如果用了，要明智地使用，且在整个工程中统一。
例子：rpt //在工程中统一表示报表
（4）要求：避免使用长的名字（小于 15 个字母是个好主意）。
（5）要求：避免使用类似的名字，或者仅仅是大小写不同的名字。
例子：userID //如果已经定义了userID，就不要定义useID,避免发生混淆。
（5）要求：除定义常量外，不使用下划线。
例子：AUTHORVAL_WRITE //定义常量表示可写权限
反例：user_ID //错误。
2.4.2 目录和文件的命名
目录命名以小写字母开头，后面每个单词的首字母大写。
文件命名以大写字母开头，后面每个单词的首字母大写。如DeclareDetail.java。
对于BPO、BO、DAO层中的JAVA文件后面增加相应简写后缀的方式。如UserManagerBPO、UserBO、UserDAO。
2.4.2 包的命名
要求：用财政部的国际域名的倒转的小写字母作为包的根，再加上项目名和各个模块的名称作为包名。包的名称只能是小写字母并且没有下划线。
例子：package gov.mof.fasp.core //正确
反例：package Gov3.mof_rpt.fasp.core //错误。
要求：类名应该是一个名词。类命名以大写字母开头，采用“驼峰”规范，后面每个单词的首字母大写。类名简洁而有意义，使用完整的单词，避免缩写词（除非该缩写词被广泛使用如URL）。对于BPO,BO,DAO层中的类后面增加相应简写后缀的方式。如UserManagerBPO、UserBO、UserDAO。
例子：class UserManagerBPO
2.4.4 接口的命名
要求：接口名称以I开头，I之后的名称遵照类的命名规范。
例子：public interface IRptDataSetService //正确。表示“报表数据集接口”。
2.4.5 变量的命名
要求：变量必须采用驼峰命名方式命名，起始必须字符小写，之后的每个单词首字母大写。
例子：private String userID; //正确。
private String userName; //正确。
注意：变量命名应遵循如下的原则：
a)标识符应当直观且可以拼读，可望文知义，容易理解和接受。
b)标识符的长度应当符合“min-length&&max-infomation”原则。
c)命名规则尽量与所采用的操作系统或开发工具的风格保持一致。
d)程序中不要出现仅靠大小写区分的相似的标识符。
e)变量名称字符应控制在15个以内。
f)尽量避免名字中出现数字编号，如Value1,Value2。
g) 如果两个变量类型一样，就用类型做前缀。如：
User userOne;
User userTwo;
2.4.6 类的属性命名
要求：类属性命名全部采用小写字母，如果需要持久化，要保证和数据库中的字段名称一样；类属性和数据库中的字段前都不用额外的加f。
例子：private String username; //正确。
要求：方法命名一般采用动词加名词，如果可能的话，使用和要赋值的字段一样的名字。方法的名字必须用一个小写字母开头。后面的单词用大写字母开头。
例子：int getSize() //正确。
2.4.8 常量的命名
要求：命名常量时用大写的字母并且每个单词之间用下划线分割。
例子：COLOR_RED //正确。
2.4.9 数组的命名
要求：变量表示集合，要用复数形式。
例子：String[] users //正确。
2.4.10 特定命名规范
（1）get/set方法
要求：get/set方法是必须在直接访问变量时使用。
例子：employee.getName(); //正确
employee.setName(name); //正确
注：sun的代码规范约定，命名属性访问方法遵守JavaBeans约定。在写JavaBean 时该规则实际是强制的。
（2）is的用法
要求：is应当在Boolean变量命名和访问方法中使用。
例子：isSet,isVisible,isFinished,isFound,isOpen.
（3）循环变量
要求：方法内部循环变量应当使用I,j,k。
注：这是一种习惯的简便用法，容易区分。
2.5 书写格式规范
2.5.1 空行
（1）每个文件末尾应该有一个空行。
（2）不得出现无规则的空行，比如连续十个空行。
（3）每个块之间增加一个空行。
（4）属性和方法之间增加一个空行。
（5） import导入包时，相关联的包组织在一起，通过一个空行隔开。
2.5.2 行数及行宽限制
（1）文件长度不应该超过2000行。
（2）每个方法的长度不应超过53行。
（3）每行代码长度不应超过120个字符，包括空格。超长的语句应注意折行格式及缩进。
（4）注释的每行长度不应超过120个字符。
2.5.3 空格的使用
（1）变量和修饰符之间应该有一个空格。
例子：StringBuffer outHtml //正确。
（2）等号两边应该各有一个空格。
例子： String str = new String(); //正确。
反例： String str=new String(); //错误。
（3）类，接口，方法以及if,else,while,for,do,switch,try,catch语句中，左大括号应与圆括号同行，并用一个空格隔开。即左大括号“{”位于声明语句同行的末尾，并且有一个空格，右大括号“}”另起一行。
例子：
ａ）类或接口声明:
public class MyClass {
…
}
ｂ）方法声明:
void method(int j) {
…
}
ｃ）for循环：
for(int i=0;i … } ｄ）if…else语句： if (…) { … } else if (…) { … } ｅ）try…catch语句 try { … } catch(Exception e) { … } finally { … } f) switch语句 switch(value) { case 0: … break; … default: … break; } （4）不要出现无意义的空格。 在行尾，注释末端，或者某一个空行中不要出现无意义的空格，虽然这些不可见字符不会影响编译，但是不会通过代码检查。 （5）在方法名与其参数列表之前的左括号”(”之间不要有空格。 例子： addRecord(name, age) //正确。 反例：addRecord( name,age) //错误的写法。 注：可以在IDE中设置，或者导入formatter模板，对代码格式化。 2.5.4 缩进与对齐 （1）每个块中的表达式都要首字母对齐。 为了提高可读性，应将多个单独的表达式放在一个块中，一致的缩进。 （2）每个缩进是4个字符宽度，用空格而不是TAB键。 （3）每一行最多只能包含一个表达式，不要将两个短的表达式放在一行。如果一行太长，应该将它分成多行以提高可读性。 例子：colNum++; rolNum--; //正确 反例：colNum++; rolNum--; //错误。 （4）折行 要求：在任何情况下, 超长的语句应该在一个逗号或者一个操作符后折行。 例子：function (param1, param2, param3); //正确 （5）内部语句的缩进 例子： class Example { int[] myArray = {1, 2, 3, 4, 5, 6 }; int theInt = 1; String someString = "Hello"; double aDouble = 3.0; … 2.6 代码内容规范 2.6.1 字符串 （1）字符串的比较 要求： String的比较不能用!=和==,而应该用equals()。 例子：if ("something".equals(x)) //正确。 反例： if (x == "something") //错误。 （2）String 和StringBuffer类的使用 要求：当需要用到多个字符串相加时，避免使用两个String变量用”+”相加的方法，而应该使用StringBuffer的append()方法追加。 （3）字符串处理 要求：a)在任何用到字符串转化为数字时，捕捉异常，对异常情况进行处理，可选择进行以下任一种处理方式： 检查到异常发生，即赋给某变量一个默认值； 检查到异常发生，提示用户使用正确的数字格式输入； b)对字符串进行截取(substring, charAt)、转换为字节数组(getBytes)，字符数组转换为字符串（valueOf）操作时，先对操作字符串对象的存在性（是否为空）及长度进行检查后，再进行操作。 2.6.2 异常处理 （1）不合理的catch 很多人经常把本应捕获多种异常的格式，简化写成：catch Exception 这一种。这样会导致无法正常捕获NPE，OutOfMemoryErrors这样的异常。而且也不能针对不同的异常进行不同的处理。这是不好的编程习惯。 要求：要将它们逐个捕获而不能用https://www.doczj.com/doc/123748724.html,ng.Exception进行捕获。 （2）不合理的throws 要求：确保某些类型不被throw. 比如说，声明抛出 https://www.doczj.com/doc/123748724.html,ng.Error, https://www.doczj.com/doc/123748724.html,ng.RuntimeException 就是不可以的。 （3）异常的使用和处理 要求：对于系统中无论如何改进代码都有可能无法避免的错误，我们使用异常。如：配置文件被删除、网络中断、数据库无法连接等。并且保证必须保证系统将所有的异常全部处理。前后台异常一致性。避免底层异常捕获后不向上传递。 2.6.3 结构控制语句 （1）if,else,while的处理语句必须有大括号 要求：就算其处理语句只有一句，也应该加上大括号，否则会让人混淆，经常导致无法预测的问题出现。 例子：if(…) { return true; } //正确写法！ 反例：if(…)r eturn true; //错误！ 反例：if (…) return true; //错误！ （2）空白区域 主要是说{} 包含起来的。比如if , else, catch 后面紧跟的。 要求：在代码中不允许出现没有处理语句的空白区域。 反例： catch(IOException e) { } //错误。 （3）丢了default分支的switch。 要求：switch语句必须包含有default分支。 （4）三目运算符“？：” 要求：避免使用三目运算符“？：”。通常情况下，会导致代码阅读难度加大，用if…else 代替。 （5）判断条件不可以包含内部赋值等执行语句；复杂的判断条件应当避免 例子：file = openFile(fileName, “w”); if(file != null) { … } //正确 反例： if((file = openFile(fileName, “w”)) != null) { … } //错误 2.6.4 关键字 （1）确保成员变量应该定义为private。 （2）多余的关键字 要求：主要是针对接口中定义方法时，不必用public static修饰。 （3）关键字顺序 要求：方法修饰符应当按如下顺序书写 其中， 2.6.5 类和方法 （1）工具类 要求：a)对于系统中用到的工具类（也即是只提供方法的类）要定义为final。 这样做防止以后有人继承该类重载其中的方法造成混淆。 b)确保只有static方法的工具类没有public的构造方法（缺省的构造方法是public的）。 （2）确保只有private构造函数的class声明成final。 （3）方法参数限制 要求：方法参数个数不要超过7个，否则会增加开发和维护的难度。 （4）方法功能 要求：方法功能应该应当单一。功能过多不利于编写和维护，代码长度也会超出限制。 （5）参数被赋值 要求：某个方法传递进来的参数，是不允许在该方法中改变值的。应定义为final。 例子：public someMethod(final String para1) { … } //正确。 反例： public someMethod(String para1) { … } //错误。 2.6.6 循环 （1）for初始语句 要求：循环控制变量之外的其他变量的初始化不可以出现在for初始语句中。 例子：sum = 0; for(int i = 0; i < 100; i++) { sum += value[i]; } //正确。 反例：for(int i = 0，sum = 0; i < 100; i++) { sum += value[i]; } //错误。 （2）循环控制变量 要求：在循环控制体内不可以修改循环控制变量 这样会导致程序逻辑复杂，带来潜在问题。 2.6.7 数据库相关 （1）JDBC的使用 要求：数据库连接必须通过datasource获得，不能自己创建新的连接。连接用完后马上释放回连接池，取得连接和释放连接必须成对出现。 使用PreparedStatement，而不提倡使用Statement。打开连接之后，不要进行数据的处理工作（例如：对数据的格式调整，顺序调整，计算等），对数据的处理工作应该在打开连接之前完成。 （2）数据读写 要求：从数据集中读取数据时要先检验是否为空，若为空要进行相应的处理。 对数据库进行多表的添加、修改和删除的操作时一定要用事务处理。数据量大的时候建议使用批量插入(addBatch)，批量删除。 减少各层之间的交互次数,减少与数据库的交互次数，多使用值对象一次完成数据传输。 （3）空格处理 要求：当接受用户输入或从数据库获取数据时应首先进行空值判断处理和过滤空格。2.6.8 其他规范 （1）数组定义风格 要求：数组声明时，必须用java风格来定义，即方括号在前。 例子：String[] users //java风格，正确。 反例：String users[] //错误。 （2）magicnumber的出现 magicnumber的出现让程序难以阅读，维护和修改更是困难。 要求：不使用magicnumber。 反例：sex = 0; //错误。难以理解。 解决办法：主要是将这些数字定义为常量,或者枚举类型。 （3）控制台输出语句。 要求：尽量不使用System.out.println()语句。在调试阶段，可以打印出堆栈的信息，一旦程序开发完成，一定要去掉堆栈信息，而要用更友好的信息来代替。 （4）Dead Code 要求：代码中不允许出现Dead Code，即不会执行到的死代码。 （5）Collection API 的使用 要求：在单线程程序中，要使用Vector时用ArrayList代替，使用Hashtable时用HashMap 代替。 在多线程中，要使用ArrayList时用Vector代替，使用HashMap时用Hashtable代替。 详细的解释参看Collection API.doc。 （6）在程序中不允许使用绝对路径。 （7）对于那些有约束条件的方法，要在其中加入断言处理。 要求：对于系统中可以通过改进代码避免的错误，我们使用断言。如对字符进行了四则运算、插入数据库的数据长度超出了数据库定义的字段长度等。 如：Asserts.ass ert(amount < 1000,”数值过大”); （8）synchronized的使用 要求：尽量不要将方法定义成synchronized，如果方法中需要访问共享资源，应只将这部分代码定义成synchronized。 （9）request和session注意 要求：从request或session中值时，采用String对象保存用户提交的结果；在如果涉及对象的操作时，先检测其是否为空后，检查到对象为空后，可再选择进行以下任一种处理方式： 处理方式 1) 检查到对象为空时，设置对象值为空字符串或一个默认值； 处理方式 2) 检测到对象为空时，根本不执行某操作，直接跳转到其他处理中。 处理方式 3) 检查到对象为空时，提示用户操作有错误。 如： String para1 = request.getParameter("name"); if (para1==null) { para1 = "Error"; } out.println(“Name is “+para1); 三．附录 JAVA文件的例子: ValidDeclare.java /* * $Title: RpgAdapter.java * Copyright (C) 2007 龙图软件。 * * Revision History: * Revision 2.5 2002-8-10 Michael 添加属性pyrNum * Revision 2.4 2002-8-1 Danies 修改initParameters方法 * */ package gov.mof.core.util; import java.io.IOException; import com.ibm.as400.access.AS400Text; import com.ibm.as400.access.ProgramParameter; /** * @ClassName: ValidDeclare * @Description: 纪录已减免税额的RPG(R#RGTDPR)程序调用。 * @author Michael 于 2002-8-10 上午10:24:36 */ public class ValidDeclare extends RpgAdapter { /** * @Fields pyrNum : 申报表号 */ private AS400Text pyrNum; /** * 创建一个新的实例，指定程序库和程序名。 */ public ValidDeclare() { pgmLibrary = "TAXOBJ"; // 程序库名称 pgmName = "R#RGTDPR"; // 程序名称 parmList = new ProgramParameter[1]; // 参数集 inputList = new String[1]; // 输入参数中间集合 pyrNum = new AS400Text(8,as400); // 纳税编码 } /** * @Description 属性pyrNum的赋值方法 * @param pyrNum 纳税编码 */ public void setPyrNum(String pyrNum) { inputList[0] = pyrNum; } /** * @Description：pyrNum的取值方法 * @return 返回一个字符串 */ public String getPyrNum() { return pyrNum; } /** * @Description:初始化参数 * @exception IOException 如果发生I/O错误 **/ public void initParameters() throws IOException { parmList[0] = new ProgramParameter(pyrNum.toBytes(inputList[0]),pyrNum.getByteLength()); } } //根据半径计算圆的周长和面积#include 数控机床标准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 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的所有操作都可以是本地的，仅仅在将新版本的内容上传到服务器上时才需要连接网络。 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} 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、严格采用阶梯层次组织程序代码： 各层次缩进的分格采用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，研发修改，再提交测试，然后预发布测试 代码编写规范说明书（c#.net与https://www.doczj.com/doc/123748724.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: 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,分割字符串[,次数][,比较方法])：以分割字符串为分割标志将字符串转为字符数组可选参数需同时选C程序代码大全
数控编程G、M、T、S代码大全(精选.)
代码规范
C语言代码大全
Git源代码管理规范
C 经典程序代码大全
CSS设计(代码)规范
编码规范详细说明_v1详解
CNC加工中心程序代码大全
源代码管理规范
程序设计规范
源代码管理规范
代码版本管理规范_v1.1
代码编写规范说明书
VB编程常用代码大全
相关主题
文本预览