源代码主干分支开发四大模式
1. 一先锋主干多稳定分支
2. 二守护主干多先锋分支
3. 三主干无分支
4. 四守护主干单分支
一、先锋主干多稳定分支
得到一个稳定版本后，将此稳定版本放到一个新分支上，针对此稳定版本的修修补补就在这个分支上进行，新功能不在此分支上开发，而在主干上进行新功能的开发。这是业界采用较多的模式。
稳定分支上的有些修改，比如缺陷修复，需要合并到主干，但有些特定修改，是不需要合并到主干的。这时需要千万注意，合并准确的文件到主干。
对于不能合并到主干的情况，常见的是再拉一个分支，这个分支专门为少数特定情况而用，但从全局讲，可能会导致太多分支，不同分支间混乱，所以这并不推荐。推荐宁愿采用配置开关。
比如freebsd的发布就是一个典型的例子。
freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable 分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个release分支。以6.x为例，就会有6.0,6.1,6.2…等发布分支。
二、守护主干多先锋分支
得到一个稳定版本后，拉出先锋分支，在分支上开发新功能，在主干上进行修修补补。当先锋分支通过一定的测试之后，合并到主干。可以同时有多个先锋分支，不同的功能可以拉不同的分支，不同发布时间点而又要同时开发的内容必须在不同的分支上。
从发布的角度讲，更推荐将肯定一起发布的内容放在相同的先锋分支上。
主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次
合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。
三、主干无分支
只有主干，没有分支，所有紧急正常的修改全在主干上，开发了一半的东西如果要上线的话，要巧妙的藏起来。对程序的结构提出了高要求，分分合合要方便，开关配置是少不了的了。单从效率讲，这是最高效的模式了。要有不少配套措施才可以。常见的配套措施：每日集成（编译部署测试），静态代码检查，测试不仅仅有单元测试，还有接口测试，还有界面自动化测试。
四、守护主干单分支
只有一个分支，紧急修改在主干上进行，正常开发在分支上进行，主干和分支根据需要双向同步。需要采用与主干无分支相同的配套手段，而且在主干和分支上都需要建设每日集成，甚至持续集成。
以上四种模式是主干分支开发的典型情况。
在实际应用中，前2种更加常见一些，
主干无分支开发时碰到极其特殊情况时，不排除拉短分支。
而在第一个模式先锋主干稳定分支开发时与第三个模式主干无分支，是可以在一段时间内相互转换的。
附:参考资料（代码的分支管理策略)
关于代码管理的分支和发布策略，目前我知道的主要有两种模式。
一种是主干作为新功能开发主线，分支用作发布。另一种是分支用作新功能开发，主干作为稳定版的发布。
前一种分支管理策略被广泛的应用于开源项目。比如freebsd的发布就是一个典型的例子。
freebsd的主干永远是current，也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定，达到一个发布的里程碑以后，从主干分出来一个stable 分支。freebsd是每个大版本一个分支。也就是说4.x，5.x，6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善，而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后，就会有一次发布。发布的时候会在稳定分支上再分出来一个release分支。以6.x为例，就会有6.0,6.1,6.2…等发布分支。
这种发布方法非常适用于产品线的发布管理。产品是要卖的，以前卖给客户的版本仍需要继续维护，而为了以后的市场，新功能也不断地在增加。这种管理方法对已发布产品的维护工作和下一代产品的开发工作进行了隔离。对于已经发布的产品，只有维护的补丁发布。而新发行的产品不仅包括了所有的bug修改，还包括了新功能。
这种方法也不是没有缺点的。首先，必须对主干上的新功能增加进行控制。只能增加下一个发布里面计划集成进去的新特性。而且，已经在主干上集成的新特性中的任何一个，如果达不到里程碑的要求，稳定分支就不能创建，这很有可能影
响下一个发布的计划。开源项目可能这方面的压力小一些，但是商业产品开发如果碰到这种情况就危险了。还有一个缺点就是bug修改必须在各个分支之间合并。从分支和合并的一些实践经验上看，各个长期存在的分支之间必须要周期性的进行合并，否则很容易引发合并冲突。可是各个stable分支以及release分支之间恰好是不能进行合并而且还要长期存在的。因此，采用这种分支策略可能碰到的最大问题就是某个分支上的bug修改内容往其它分支merge的时候出现的冲突。而且一旦发现一个bug，调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加。
在非产品开发的外包软件项目里面，这种发布方法的好处体现不出来，而缺点仍然存在。外包项目的特点是客户永远需要“最新”的代码，因此对已经发布的某个分支进行维护的情况很少出现（在测试的时候会出现）。而且发布的方法和产品的发布也不一样。产品的发布，只要把发布分支上的代码编译成安装盘就可以了，而外包的发布往往是把上一次发布和这一次发布之间发生变化的代码送给客户。如果每次发布都是一个分支的话，将会出现两个分支上的比较。强大的版本控制工具当然支持这种比较，但是很多版本工具不支持分支之间的比较，而只支持分支内的不同版本之间的比较。因此为了避免发布方法受工具的限制，就要避免出现分支间比较的情况。针对外包开发的特殊情况，只有采用另外一种分支管理策略。
与第一种分支策略正好相反，主干上永远是稳定版本，可以随时发布。bug的修改和新功能的增加，全部在分支上进行。而且每个bug和新功能都有不同的开
发分支，完全分离。而对主干上的每一次发布都做一个标签而不是分支。分支上的开发和测试完毕以后才合并到主干。
这种发布方法的好处是每次发布的内容调整起来比较容易。如果某个新功能或者bug在下一次发布之前无法完成，就不可能合并到主干，也就不会影响其他变更的发布。另外，每个分支的生命期比较短，唯一长期存在的就是主干，这样每次合并的风险很小。每次发布之前，只要比较主干上的最新版本和上一次发布的版本就能够知道这次发布的文件范围了。
这种发布模式也有缺点。如果某个开发分支因为功能比较复杂，或者应发布计划的要求而长期没有合并到主干上，很可能在最后合并的时候出现冲突。因此必须时刻注意分支离开主干的时间。如果有的分支确实因为特殊的需要必须长期存在，那就必须定期把主干的更新往这个分支上合并。为了减少这种合并发生的次数，并且限定合并的范围，要为每次发布预先建立一个发布分支，然后所有的开发分支根据自己的发布计划向各个发布分支合并。当下一次发布的分支上已经集成了所有的变更并且测试完毕以后，把这个发布分支内容合并到主干，发布主干，然后锁定或者删除这个分支。然后把主干上的所有更新合并到后面几个发布分支里面去。外包项目的发布周期一般都比较短，往往客户验收测试的周期就是发布周期。所以这种方法就够用了。如果发布周期很长，各个发布分支之间还要定期的从前向后合并。这种发布方法还有一个缺点就是测试。不像第一种分支策略，发布的分支就是测试的分支。这种发布模式的测试分支往往是各个发布分支，在正式发布之前才把下一个发布分支上的更新合并到主干，这就引入了合并出错的风险，而主干上的程序是没有经过测试的。幸好从这个发布模式上看，下一个发布
分支的合并基础应该和主干上一次发布内容相同，所以引入合并错误的风险很低。还有一种建议就是不设置主干，下一个发布分支就是主干，直接发布下一个发布分支的变更内容，然后把变更合并到再下一个发布分支上去。以此类推。有机会尝试一下。
最后，说说分支合并管理的一些注意点：
1.分支离开主干的时间要尽可能短。长期离开主干的分支需要定期合并。
2.辅助文档是必需的。为了观察分支的创建和合并的过程，至少需要一份类似泳道图的文档标记每一次分支创建和合并的过程。
3.开发分支往主干或者发布分支合并的次数应该尽可能少。一般来讲应该在单体测试结束合并到主干或者发布分支，然后进行结合测试。如果结合测试里发现bug不应该在原来的开发分支上继续修改，而应该创建新的分支进行修改。
4.分支创建和合并的log必须规范。便于以后查找。基本的log信息应该包括从哪个个分支的哪个版本创建分支；把哪个分支的从哪版本到哪个版本范围内的变更合并到了哪个分支的哪个版本，合并后的版本号。这些信息有一些是版本控制工具本身可以很方便查找到的，就可以省略
软件开发规范 1 排版 11-1：程序块要采用缩进风格编写，缩进的空格数为4个。 说明：对于由开发工具自动生成的代码可以有不一致。 11-2：相对独立的程序块之间、变量说明之后必须加空行。 示例：如下例子不符合规范。 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 11-3：较长的语句（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐，语句可读。 示例： = NO7_TO_STAT_PERM_COUNT_LEN + STAT_SIZE_PER_FRAM * sizeof( _UL ); act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied = stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false
= SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0));
软件开发代码规范（C#版） 拟制:日期：2007-2-13审核:日期： 审核:日期： 批准:日期： 版权所有 ********有限公司
修订纪录
目录 注：Pascal命名法则：即名称中所有单词的第一个字母大写其他字母使用
小写形式。 Camel命名法则：即名称中第一个单词各个字母全部小写，其他部分遵循Pascal命名法则。 1、第一章命名规范 1.1、第一节总则 1．本命名规则除特殊提及外统一使用Camel命名法则。 如：controlMenu 2．命名时尽量不使用拼音，更不可使用拼音缩写（专有名词除外）。 3．如果使用品牌名称命名时其大小写尽量保持和品牌名称一致的样式。 如：LuX则命名时，不要写成LUX，或者Lux，而应该保持与原品牌名称风格一致使用LuX 4．使用专有名词或英文缩写命名时采用大写形式。 如：CNNIC 5．禁止使用仅区分大小写的方式命名。 如：Abc与abc仅用大写A来区分，这样写在类C系语言中不会出错，但是不利于系统的迁移
、第二节变量命名规范 1.2.1、CodeBehind内部命名规范 1．公有字段/属性使用Pascal 命名规则，私有变量/保护变量/局部变量使用Camel命名规则，遵循动宾结构。 例： public class Hello { private string userName; private DateTime loginTime; private bool isOnline; public string UserName { get { return ; } } } 2．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名，如 i 或 j 3．在变量名中使用互补对，如 Min/Max、Begin/End 和 Open/Close。 4．当一个方法内部变量繁多的时候，可以使用Camel命名法则，其中第一个单词可以使用变量类型的缩写来说明以示区别。 例：
1、概念： 分支定界算法(Branch and bound，简称为BB、B&B, or BnB)始终围绕着一颗搜索树进行的，我们将原问题看作搜索树的根节点，从这里出发，分支的含义就是将大的问题分割成小的问题。大问题可以看成是搜索树的父节点，那么从大问题分割出来的小问题就是父节点的子节点了。分支的过程就是不断给树增加子节点的过程。而定界就是在分支的过程中检查子问题的上下界，如果子问题不能产生一比当前最优解还要优的解，那么砍掉这一支。直到所有子问题都不能产生一个更优的解时，算法结束。 2、例子： 用BB算法求解下面的整数规划模型 因为求解的是最大化问题，我们不妨设当前的最优解BestV为-INF，表示负无穷。 1.
首先从主问题分出两支子问题： 通过线性松弛求得两个子问题的upper bound为Z_LP1 = 12.75，Z_LP2 = 12.2。由于Z_LP1 和Z_LP2都大于BestV=-INF，说明这两支有搞头，继续往下。 2. 3.
从节点1和节点2两个子问题再次分支，得到如下结果： 子问题3已经不可行，无需再理。子问题4通过线性松弛得到最优解为10，刚好也符合原问题0的所有约束，在该支找到一个可行解，更新BestV = 10。 子问题5通过线性松弛得到upper bound为11.87>当前的BestV = 10，因此子问题5还有戏，待下一次分支。而子问题6得到upper bound为9<当前的BestV = 10，那么从该支下去找到的解也不会变得更好，所以剪掉！ 4.
对节点5进行分支，得到： 子问题7不可行，无需再理。子问题8得到一个满足原问题0所有约束的解，但是目标值为4<当前的BestV=10，所以不更新BestV，同时该支下去也不能得到更好的解了。 6.
软件开发代码规范（C） (仅通普信息技术股份有限公司供内部使用) 拟制：杨超日期：2015-3-10审核：夏峰日期：2015-3-10核准：冯敬刚日期：2015-3-17签发：韩殿成日期：2015-3-21文档版本：V1.11 黑龙江通普信息技术股份有限公司
版本历史
目录 第一章代码开发规范及其指南 0 1.1目的 0 1.2程序内命名规范 0 1.3文件命名规范 (1) 1.4J AVA 文件样式 (1) 1.5代码编写格式 (6) 第二章程序编写规范方法 (8) 2.1权限修饰 (8) 2.2其他规范 (8) 2.3编程指南 (10) 第三章其他要求 (12)
第一章代码开发规范及其指南 1.1 目的 定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。（这些规范并不是一定要绝对遵守，但是一定要让程序有良好的可读性） 1.2 程序内命名规范 ●Package的命名：Package 的名字应该都是由一个小写单词组成。 ●Class 的命名：Class 的名字必须由大写字母开头而其他字母都小写的单词组 成 ●Class 变量的命名：变量的名字必须用一个小写字母开头。后面的单词用大 写字母开头。 ●Static Final 变量的命名：Static Final 变量的名字应该都大写，并且指出完整 含义。 ●参数的命名：参数的名字必须和变量的命名规范一致。 ●数组的命名：数组应该总是用下面的方式来命名： byte[] buffer; 而不是 byte buffer[]; ●方法的参数：使用有意义的参数命名，如果可能的话，使用和要赋值的字 段一样的名字： SetCounter(int size){ this.size = size;
软件开发代码规范（C#版） 拟制: 日期：2007-2-13 审核: 日期： 审核: 日期： 批准: 日期： 版权所有********有限公司
修订纪录
目录 1、第一章命名规范 (4) 1.1、第一节总则 (4) 1.2、第二节变量命名规范 (4) 1.2.1、CodeBehind内部命名规范 (4) 1.2.2、控件命名规范 (5) 1.3、第三节常量命名规范 (5) 1.4、第四节命名空间、类、方法命名规范 (5) 1.5、第五节接口命名规范 (6) 1.6、第六节命名规范小结 (6) 2、第二章代码注释规范 (6) 2.1、第一节模块级注释规范（命名空间、类等） (6) 2.2、第二节方法级注释规范 (7) 2.2.1 、属性注释 (7) 2.2.2 、方法注释 (7) 2.3、第三节代码间注释规范 (8) 3、第三章编写规范 (9) 3.1、第一节格式规范 (9) 3.2、第二节编程规范 (9) 3.2.1 、程序结构要求 (9) 3.2.2 、可读性要求 (10) 3.2.3 、结构化要求 (10) 3.2.4 、正确性与容错性要求 (10) 3.2.5 、可重用性要求 (11) 3.2.6 、interface使用注意事项 (11) 3.2.7 、类使用注意事项 (11) 3.2.8 、流程控制语句注意事项 (12) 3.2.8 、其他应注意事项 (13) 注：Pascal命名法则：即名称中所有单词的第一个字母大写其他字母使用小写形式。 Camel命名法则：即名称中第一个单词各个字母全部小写，其他部分遵循Pascal命名法则。
1、第一章命名规范 1.1、第一节总则 1．本命名规则除特殊提及外统一使用Camel命名法则。 如：controlMenu 2．命名时尽量不使用拼音，更不可使用拼音缩写（专有名词除外）。 3．如果使用品牌名称命名时其大小写尽量保持和品牌名称一致的样式。 如：LuX则命名时，不要写成LUX，或者Lux，而应该保持与原品牌名称风格一致使用LuX 4．使用专有名词或英文缩写命名时采用大写形式。 如：CNNIC 5．禁止使用仅区分大小写的方式命名。 如：Abc与abc仅用大写A来区分，这样写在类C系语言中不会出错，但是不利于系统的迁移 1.2、第二节变量命名规范 1.2.1、CodeBehind内部命名规范 1．公有字段/属性使用Pascal 命名规则，私有变量/保护变量/局部变量使用Camel命名规则，遵循动宾结构。 例： public class Hello { private string userName; private DateTime loginTime; private bool isOnline; public string UserName { get { return https://www.doczj.com/doc/ef5792149.html,erName; } } } 2．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名，如i 或j 3．在变量名中使用互补对，如Min/Max、Begin/End 和Open/Close。 4．当一个方法内部变量繁多的时候，可以使用Camel命名法则，其中第一个单词可以使用变量类型的缩写来说明以示区别。 例：
Linprogdis子程序: function [x,fval,exitflag,output,lambda]=... linprogdis(ifint,f,A,b,Aeq,beq,lb,ub,x0,options) %Title: % 分支定届法求解混合整数线性规划模型 % %初步完成：2002年12月 %最新修订: 2004-03-06 %最新注释：2004-11-20 %数据处理 [t1,t2] = size(b); if t2~=1, b=b';%将b转置为列向量 end %调用线性规划求解 [x,fval,exitflag,output,lambda] = linprog(f,A,b,Aeq,beq,lb,ub,x0,options); if exitflag<=0,%如果线性规划失败，则本求解也失败 return end %得到有整数约束的决策变量的序号 v1=find(ifint==1);%整数变量的index tmp=x(v1);%【整数约束之决策变量】的当前值 if isempty(tmp), %无整数约束，则是一般的线性规划，直接返回即可 return end v2=find(checkint(tmp)==0);%寻找不是整数的index if isempty(v2), %如果整数约束决策变量确实均为整数，则调用结束 return end %第k个决策变量还不是整数解 %注意先处理第1个不满足整数约束的决策变量 k=v1(v2(1)); %分支1：左分支 tmp1=zeros(1,length(f));%线性约束之系数向量 tmp1(k)=1; low=floor(x(k)); %thisA 分支后实际调用线性规划的不等式约束的系数矩阵A %thisb 分支后实际调用线性规划的不等式约束向量b if ifrowinmat([tmp1,low],[A,b])==1 %如果分支的约束已经存在旧的A，b中，则不改变约束 thisA= A; thisb= b;
整数规划分支定界法MATLAB 程序 1.这种方法绝对能都解出答案，而且答案正确function [x,val]=fzdj(n,f,a,b,aeq,beq,lb,ub) x=zeros(n,1); x1=zeros(n,1); m1=2; m2=1; [x1,val1]=linprog(f,a,b,aeq,beq,lb,ub); if (x1==0) x=x1; val=val1; elseif (round(x1)==x1) x=x1; val=val1; else e1={0,a,b,aeq,beq,lb,ub,x1,val1}; e(1,1)={e1}; zl=0; zu=-val1; while (zu~=zl) for c=1:1:m2 if (m1~=2) if (cell2mat(e{m1-1,c}(1))==1) e1={1,[],[],[],[],[],[],[],0}; e(m1,c*2-1)={e1}; e(m1,c*2)={e1}; continue; end; end; x1=cell2mat(e{m1-1,c}(8)); x2=zeros(n,1); s=0; s1=1; s2=1; lb1=cell2mat(e{m1-1,c}(6)); ub1=cell2mat(e{m1-1,c}(7)); lb2=cell2mat(e{m1-1,c}(6)); ub2=cell2mat(e{m1-1,c}(7)); for d=1:1:n if (abs((round(x1(d))-x1(d)))>0.0001)&(s==0) s=1; lb1(d)=fix(x1(d))+1; if (a*lb1<=b) s1=0; end; ub2(d)=fix(x1(d)); if (a*lb2<=b) s2=0; end; end; end; e1={s1,a,b,aeq,beq,lb1,ub1,[],0}; e2={s2,a,b,aeq,beq,lb2,ub2,[],0}; e(m1,c*2-1)={e1}; e(m1,c*2)={e2}; end; m1=m1+1;
软件开发代码规（C#版） 拟制: 日期：2007-2-13 审核: 日期： 审核: 日期： 批准: 日期： 所有 ********
修订纪录
目录 1、第一章命名规 (4) 1.1、第一节总则 (4) 1.2、第二节变量命名规 (4) 1.2.1、CodeBehind部命名规 (4) 1.2.2、控件命名规 (5) 1.3、第三节常量命名规 (5) 1.4、第四节命名空间、类、方法命名规 (5) 1.5、第五节接口命名规 (6) 1.6、第六节命名规小结 (6) 2、第二章代码注释规 (6) 2.1、第一节模块级注释规（命名空间、类等） (6) 2.2、第二节方法级注释规 (7) 2.2.1 、属性注释 (7) 2.2.2 、方法注释 (7) 2.3、第三节代码间注释规 (8) 3、第三章编写规 (8) 3.1、第一节格式规 (8) 3.2、第二节编程规 (9) 3.2.1 、程序结构要求 (9) 3.2.2 、可读性要求 (9) 3.2.3 、结构化要求 (10) 3.2.4 、正确性与容错性要求 (10) 3.2.5 、可重用性要求 (10) 3.2.6 、interface使用注意事项 (11) 3.2.7 、类使用注意事项 (11) 3.2.8 、流程控制语句注意事项 (12) 3.2.8 、其他应注意事项 (13) 注：Pascal命名法则：即名称中所有单词的第一个字母大写其他字母使用小写形式。 Camel命名法则：即名称中第一个单词各个字母全部小写，其他部分遵循Pascal命名法则。
1、第一章命名规 1.1、第一节总则 1．本命名规则除特殊提及外统一使用Camel命名法则。 如：controlMenu 2．命名时尽量不使用拼音，更不可使用拼音缩写（专有名词除外）。 3．如果使用品牌名称命名时其大小写尽量保持和品牌名称一致的样式。 如：LuX则命名时，不要写成LUX，或者Lux，而应该保持与原品牌名称风格一致使用LuX 4．使用专有名词或英文缩写命名时采用大写形式。 如：CNNIC 5．禁止使用仅区分大小写的方式命名。 如：Abc与abc仅用大写A来区分，这样写在类C系语言中不会出错，但是不利于系统的迁移 1.2、第二节变量命名规 1.2.1、CodeBehind部命名规 1．公有字段/属性使用Pascal 命名规则，私有变量/保护变量/局部变量使用Camel命名规则，遵循动宾结构。 例： public class Hello { private string userName; private DateTime loginTime; private bool isOnline; public string UserName { get { return https://www.doczj.com/doc/ef5792149.html,erName; } } } 2．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名，如 i 或 j 3．在变量名中使用互补对，如 Min/Max、Begin/End 和 Open/Close。 4．当一个方法部变量繁多的时候，可以使用Camel命名法则，其中第一个单词可以使用变量类型的缩写来说明以示区别。 例：
"\n"。 HTML Tab。 作
遵循下面列出的准则有利于编写更加安全的代码。但是总体来说，这些准则不能对安全性做出任何保证。遵循这些准则可能好的实践，但是即使遵循了这些准则，写出的代码仍然可能是不安全的。风险永远存在，不管在编写代码时是如何的警觉。 这些准则的目标，不是为了保证代码的安全性，而是为了消除若干特定类型攻击带来的风险。遵循这些准则，某些特定类型的攻击将无法实现；但是其它类型的攻击仍然可能成功。因此遵循这些准则仅仅是安全的第一步。当书写可能和非守信链接或混用的代码时，应当仔细的考虑如下准则： ?静态字段 ?缩小作用域 ?公共方法和字段 ?保护包 ?尽可能使对象不可变（immutable） ?序列化 ?清除敏感信息 1) 静态字段 避免使用非final的公共静态变量，应尽可能地避免使用非final公共静态变量，因为无法判断代码有无权限改变这些静态变量的值。 一般地，应谨慎使用可变的静态状态，因为这可能导致设想中应该相互独立的子系统之间发生不曾预期的交互。 2) 缩小作用域 作为一个惯例，尽可能缩小成员方法和成员变量的作用域。检查包访问权限成员（package-private）能否改成私有成员（private），保护访问成员（protected）可否改成包访问权限成员（package-private）/私有成员（private）等等。 3) 公共方法/字段 公共变量应当避免使用，访问这些变量时应当通过getter/setter法。在这种方式下，必要时可以增加集中的安全检查。 任何能够访问或修改任何敏感内部状态的公共方法，务必包含安全检查。 参考如下代码段，该代码段中不可信任代码可能修改TimeZone的值： private static TimeZone defaultZone = null; public static synchronized void setDefault(TimeZone zone) { defaultZone = zone;
软件开发代码规范（C）（仅通普信息技术股份有限公司供内部使用） 黑龙江通普信息技术股份有限公司 版本历史
目录 第一章代码开发规范及其指南 (1) 1.1 目的 (1) 1.2 程序内命名规范 (1)
1.3 文件命名规范 (2) 1.4 J AVA文件样式 (2) 1.5 代码编写格式 (6) 第二章程序编写规范方法 (8) 2.1 权限修饰 (8) 2.2 其他规范 (8) 2.3 编程指南 (10) 第三章其他要求 (12)
第一章代码开发规范及其指南 1.1 目的 定义这个规范的目的是让项目中所有的文档都看起来像一个人写的，增加可读性，减少项目组中因为换人而带来的损失。（这些规范并不是一定要绝对遵守，但是一定要让程序有良好的可读性） 1.2 程序内命名规范 Package的命名：Package的名字应该都是由一个小写单词组成。 Class 的命名：Class 的名字必须由大写字母开头而其他字母都小写的单词组成Class变量的命名：变量的名字必须用一个小写字母开头。后面的单词用大写字母开头。 Static Final 变量的命名：Static Final 变量的名字应该都大写，并且指出完整含义。 参数的命名：参数的名字必须和变量的命名规范一致。 数组的命名：数组应该总是用下面的方式来命名：byte[] buffer; 而不是byte buffer[]; 方法的参数：使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字： SetCounter(int size){ this.size = size; }
1.3文件命名规范 文件名由英文单词组成，每个单词的首字母大写，不要超过4个单词, 如ShipOrder.jsp Java文件的文件名要与程序中的public类名相同。 Servet文件要以Servlet做为结尾，如AddCompanyServlet.java 业务处理组 件Java Bean要以Bean为结尾，如ProcessBean.java 1.4 Java文件样式 所有的Java(*java)文件都必须遵守如下的样式规则 头部 版权信息 版权信息必须在java文件的开头，比如： 其他不需要出现在javadoc的信息也可以包含在这里。 Package/lmports package行要在import行之前，import中标准的包名要在本地的包名之前，而且按照字母顺序排列。如果import行中包含了同一个包中的不同子目 录，则应该用*来处理。 package hotlava .n et.stats; import java.io.*; import java.util.Observable; import hotlava.util.Applicati on;
精心整理软件安全开发编码规范 1. 代码编写 1) 开发人员应保证工程中不存在无用的资源（如代码、图片文件等）。 2) 3) 4) ● ● ● ● ● 5) 6) 7) 8) 9) 13) 在进行log的获取时开发人员应尽量使用isXXXEnabled。 14) log的生成环境上尽量避免输出文件名和行号。 15) 产品中不要包含后门代码，隔离系统中的后门代码，确保其不能出现在产品中。作为一种 特殊的调试代码，后门访问代码是为了使开发者和测试工程师访问一部分终端用户不能访问的程序代码。但是，如果后门代码被留到产品中，对攻击者来说，它就是一条不需要通过正常安全手段来攻陷系统的通路。
2. JAVA安全 遵循下面列出的准则有利于编写更加安全的代码。但是总体来说，这些准则不能对安全性做出任何保证。遵循这些准则可能好的实践，但是即使遵循了这些准则，写出的代码仍然可能是不安全的。风险永远存在，不管在编写代码时是如何的警觉。 这些准则的目标，不是为了保证代码的安全性，而是为了消除若干特定类型攻击带来的风险。遵循这些准则，某些特定类型的攻击将无法实现；但是其它类型的攻击仍然可能成功。因此遵循这些准则仅仅是安全的第一步。当书写可能和非守信链接或混用的代码时，应当仔细的考虑如下准则： ? ? ? ? ? ? ? 1) 2) （ 3) 以增加集中的安全检查。 任何能够访问或修改任何敏感内部状态的公共方法，务必包含安全检查。 参考如下代码段，该代码段中不可信任代码可能修改TimeZone的值： privatestaticTimeZonedefaultZone=null; publicstaticsynchronizedvoidsetDefault(TimeZonezone) { defaultZone=zone;
软件开发代码规范（仅供内部使用） 拟制: 审核: 核准: 签发: 文档版本：V0.11日期: 日期: 日期: 日期: 2011-5-11
目录 第一章原则 (4) 第二章排版 (5) 2.1 空行 (5) 2.2 代码行 (6) 2.3 代码行内的空格 (6) 2.4 对齐缩进 (7) 2.5 长行拆分 (8) 第三章注释 (10) 3.1 通用规则 (10) 3.2 文件注释 (10) 3.3 函数注释 (11) 3.4 数据注释 (12) 3.5 代码注释 (12) 第四章命名 (15) 4.1 通用命名规则 (15) 4.2 文件命名 (15) 4.3 类型命名 (15) 4.4 变量命名 (16) 4.5 常量命名 (17) 4.6 函数命名 (17) 4.7 枚举命名 (17) 4.8 宏命名 (18)
第五章杂项 (19)
文件修改记录
第一章原则 本文档的目的是提供一个公共的编码规范。 这个规范详细阐述在编码时要怎样写、不要怎样写，旨在提高代码的可读性、可维护性, 使代码易于管理，使所有人可以集中精力去实现内容，而非处理各种复杂的表现形式。 使代码易于管理的方法之一是增强代码一致性，让别人可以读懂你的代码是很重要的，保持统一编程风格意味着可以轻松根据模式匹配”规则推断各种符号的含义。创建通用的、 必需的习惯用语和模式可以使代码更加容易理解。虽然在某些情况下改变一些编程风格可能 会是好的选择，但我们还是应该遵循一致性原则，尽量不这样去做。 关键在于保持一致。
第二章排版 2.1 空行 【规则2-1-1】在每个函数、结构体、枚举定义结束之后都要加空行。 【规则2-1-2】在一个函数体内，逻辑密切相关的语句之间不加空行，其它地方应加空行分隔。 【规则2-1-3】相对独立的程序块之间、变量说明之后必须加空行。 不规范代码规范代码
整数线性规划之分支定界法 摘要 最优化理论和方法是在上世纪 40 年代末发展成为一门独立的学科。1947年，Dantaig 首先提出求解一般线性规划问题的方法，即单纯形算法，随后随着工业革命、计算机技术的巨大发展，以及信息革命的不断深化，到现在的几十年时间里，它有了很快的发展。目前，求解各种最优化问题的理论研究发展迅速，例如线性规划、非线性规划以及随机规划、非光滑规划、多目标规划、几何规划、整数规划等，各种新的方法也不断涌现，并且在军事、经济、科学技术等方 面应用广泛，成为一门十分活跃的学科。 整数规划（integer programming）是一类要求要求部分或全部决策变量取整数值的数学规划，实际问题中有很多决策变量是必须取整数的。本文主要介绍求解整数线性规划问题的分支定界法及其算法的matlb实现。 关键词：整数线性规划；分支定界法；matlb程序；
1．引言 1.1优化问题发展现状 最优化理论与算法是一个重要的数学分支，它所讨论的问题是怎样在众多的方案中找到一个最优的方案.例如，在工程设计中，选择怎样的设计参数，才能使设计方案既满足要求又能降低成本；在资源分配中，资源有限时怎样分配，才能使分配方案既可以满足各方面的要求，又可以获得最多的收益；在生产计划安排中，怎样设计生产方案才能提高产值和利润；在军事指挥中，确定怎样的最佳作战方案，才能使自己的损失最小，伤敌最多，取得战争的胜利；在我们的生活中，诸如此类问题，到处可见.最优化作为数学的一个分支，为这些问题的解决提供了一些理论基础和求解方法. 最优化是个古老的课题.长期以来，人们一直对最优化问题进行着探讨和研究.在二十世纪四十年代末，Dantzig 提出了单纯形法，有效地解决了线性规划问题，从而最优化成为了一门独立的学科。目前，有关线性规划方面的理论和算法发展得相当完善,但是关于非线性规划问题的理论和算法还有待进一步的研究，实际应用中还有待进一步的完善。传统的非线性全局最优化方法只能求出问题的局部最优解，但由于许多问题的局部最优解不一定是全局最优解，使得传统的非线性最优化方法不能直接成功地应用于求解非线性全局最优化问题。另外，没有一个固定的评判标准来判断得到的局部最优解是否为全局最优解。随着科学技术的发展和计算机计算能力的提高，最优化理论在最近这几年来得到了迅速的发展，涌现出了许多新的算法, 如打洞函数法,填充函数法，lagrangian 乘子函数方法，信赖域方法，虑子方法等。 本文主要介绍求解整数线性规划问题的分支定界法及其算法的matlb实现。 1.2整数线性规划及其数学模型 整数规划主要有以下三大类： （1）全整数规划（all integer programming）：所有的决策变量都取整数值，也称为纯整数规划（pure integer programming）； （2）混合整数规划（mixed integer programming）：仅要求一部分决策变量取整数值； （3）0-1规划（zero-one integer programming）：该类问题的决策变量只能取0或1. 本文主要讨论的整数线性规划问题模型为：
软件项目开发和管理规范 版本V1.0 2010年1月15日
目录 1.软件项目管理概述 (3) 2.软件项目管理过程 (3) 3.软件项目管理内容 (5) 3.1.需求阶段管理 (5) 3.2.设计阶段管理 (7) 3.3.开发阶段管理 (7) 3.4.测试阶段管理 (8) 3.5.维护阶段管理 (8) 3.6.工具管理 (8) 3.7.软件项目估算与进度管理 (9) 3.7.1.软件项目估算 (9) 3.7.2.进度安排 (10)
1.软件项目管理概述 软件项目管理是软件工程和项目管理的交叉学科，软件项目管理的概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI 对项目管理的定义可以将软件项目管理定义为：在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体要求。 软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展。 软件生存周期包括可行性分析与项目开发计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动，所有这些活动都必须进行管理，在每个阶段都存在着权限角色控制、文档管理、版本控制、管理工具等，软件项目管理贯穿于软件生命的演化过程之中。 2.软件项目管理过程 为保证软件项目获得成功，必须对软件开发项目的工作范围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等做到心中有数。软件项目的管理工作开始于技术工作开始之前，在软件从概念到实现的过程中持续进行，最后终止于软件开发工作结束。 根据公司的实际情况，结合软件工程及软件过程标准等，特制定我公司软件项目管理流程如下：
目录 1. 目的 为了统一公司软件开发的设计过程中关于代码编写时的编写规范和具体开发工作时的编程规范，保证代码的一致性，便于交流和维护，特制定此规范。 2. 范围 本规范适用于开发组全体人员，作用于软件项目开发的代码编写阶段和后期维护阶段。 3. 注释规范 .概述 a) 注释要求中文及中文的标点符号。 b) 注释中，应标明对象的完整的名称及其用途，但应避免对代码过于详细的描述。 c) 每行注释的最大长度为100个字符。 d) 将注释与注释分隔符用一个空格分开。 e)不允许给注释加外框。 f)编码的同时书写注释。 g)重要变量必须有注释。
h)变量注释和变量在同一行，所有注释必须对齐，与变量分开至少两个空格。 如： string title; 模块（类）注释 模块开始必须以以下形式书写模块注释： 类属性注释 在类的属性必须以以下格式编写属性注释： 方法注释 在类的方法声明前必须以以下格式编写注释 代码间注释 代码间注释分为单行注释和多行注释： 单行注释： 命名总体规则 ?名字应该能够标识事物的特性，是有意义的，描述性的词语。能够一眼看出它作什么。 别使用会引起误解的名字。如果名字一目了然，就无需用文档来解释方法的功能了。?名字尽量使用英文单词。 ?名字尽量不使用缩写，除非它是众所周知的。 ?名字可以有两个或三个单词组成，但不应多于三个，控制在3至30个字母以内。 ?在名字中，多个单词用大写第一个字母（其它字母小写）来分隔。例如：IsSuperUser。?名字尽量使用前缀而不是后缀。 ?名字中的单词尽量使用名词，如有动词，也尽量放在后面。例如：FunctionUserDelete （而不是FunctionDeleteUser）。 在具体任务开发中，如果有特定的命名约定，则在相应的软件开发计划中予以明确定义及上报。 5. 命名规范 具体可参考微软命名规范 . 命名规范样式的分类
分支定界法 分支定界法，顾名思义，就是按照定好的界进行分支。这里说的分支意思是“剪枝”。剪的枝是问题解空间树的枝。所谓解空间树，即此问题所有解和中间解形成的树型结构，是有序的。常有排列树和子集树之分，举个例子，n个物品的0-1背包问题的解空间树就是子集树(每个物品都可能为0或1)，而最短路径问题的解空间树是一颗排列树。 分支定界法一般有两种实现形式：1.优先队列法2.FIFO队列法。这与分支定界的思想无太多本质联系，只是前者在一般情况下能更快的求得问题解。分支定界法要对问题的解空间树进行“剪枝”操作以减少对解空间树的搜索。那么问题是，如何“剪枝”？这就要回答如何定界的问题。在分支定界法中，“界”的作用就是用来阻止对不可行分支的搜索的。当解空间树很深时（叶子节点为解），如果能在前面几层就预先的知道了“此路不通”或者“此路不是最优”而停止此路的继续，这样能大幅度的提高算法效率。如何定界要放入具体问题中考虑，一般可以以“理论最大最小”这个概念来求界。以0-1背包问题为例，设所有物品预先已经按照单位价值量递减排列。在解空间树的第i层（此时正在考虑第i个物品是否应该被放入的时刻），设左子树为放入i物品，右子树为不放i物品。那么在确定左子树的上界的时候有：界=当前价值+i
的价值+MaxValue(背包剩余重量-i物品重量);其中的MaxValue为放i后剩余背包容量能获得的最大价值，应该注意的是此最大价值为理论意义上的最大价值，比如在继续放入p个后(按单位价值量递减),放不下第p+1个，此时应该按(Value[p+1]/Weight[p+1])*(WeightLeft)来计p+1物品的价值,(实际中不可能放入零点几个某物品。。。)；右子树的情形类似。 知道了如何定界，那么在实际流程中就要根据当前目标节点的界来剪枝了（是用上界还是下界，具体问题具体分析）。今天准备举个稍微有点挑战的例子---NPC问题中的TSP问题。 在TSP问题中，由于是环路，每个节点都要进出各一次，我们可以将每个节点最小的入度和最小的出度的和累加作为一个下界，这个下界几乎不可能达到！（全部最小出度的和即为下面提到的rcost的初值） 初始时我们创建一个最小堆，表示活节点队列。堆中按照每个节点的下界来划分优先级，下界越小的优先级越高。由于有是要求回路最小值，所以可以先判断此图是否有回路，没有直接返回，有再继续往下做。然后开始解空间树的搜索，广度优先遍历当前点的连通点，用curcost 来存当前的耗费总和，rcost表示当前点到叶子节点最小出度之和，那么一个节点的下界计算为：curcost+rcost-MinOut(当前点);如果此下界小于当前最优值，则将这个连
软 件 开 发 流 程 规 V1.0 德联软件有限责任公司 编制人：侯秀美审核人：2015 年8 月19 日
目录 目录 0 一、概述 (2) 二、开发流程规 (3) 2.1 系统软硬件开发环境 (3) 2.2 系统架构（系统组成） (5) 2.3 系统功能模块设计 (6) 2.4 系统功能开发流程图 (6) 2.5 开发修改记录 (7) 三、开发代码规 (8) 3.1 文件结构 (8) 3.1.1 文件信息声明 (8) 3.1.2 头文件的结构 (10) 3.1.3 定义文件的结构 (11) 3.1.4 头文件的作用 (12) 3.1.5 目录结构 (13) 3.2 命名规则 (13) 3.2.1 共性原则 (13) 3.2.2 Windows变量命名规则 (14) 3.3 程序风格 (16) 3.3.1 空行 (17) 3.3.2 代码行 (18) 3.3.3 代码行的空格 (19) 3.3.4 对齐 (20) 3.3.5 长行拆分 (22) 3.3.6 修饰符的位置 (23) 3.3.7 注释 (23) 3.4 函数设计 (26) 3.4.1 参数的规则 (26) 3.4.2 返回值的规则 (27) 3.4.3 函数部实现的规则 (30) 3.4.4 其它建议 (32) 3.4.5 使用断言 (32) 3.4.6 引用与指针的比较 (33) 3.5 变量类型定义 (35) 四、软件测试规 (36) 4.1 单元测试 (36) 4.2 系统测试 (37) 4.6 业务测试 (38) 4.7 验收测试 (38)
4.8 用户现场测试 (38) 五、软件版本管理 (39) 4.1版本管理的必要性 (39)
软件安全开发编码规范 1. 代码编写 1) 开发人员应保证工程中不存在无用的资源（如代码、图片文件等）。 2) 代码中每个类名上的注释必须留下创建者和修改者的名字。 3) 每个需要import的类都应使用一行import声明，不得使用import xxx.*。 4) System.out.println()仅在调试时使用，正式代码里不应出现。 5) 开发人员编写代码时应遵循以下命名规则： ●Package 名称应该都是由一组小写字母组成； ●Class 名称中的每个单词的首字母必须大写； ●Static Final 变量的名称全用大写，并且名称后加注释； ●参数的名称必须和变量的命名规范一致； ●使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名称。 6) 代码应该用unix的格式，而不是windows的。 7) exit 除了在main 中可以被调用外，其他的地方不应被调用。 8) 代码中应尽量使用interfaces，不要使用abstract类。 9) 在需要换行的情况下，尽量使用println 来代替在字符串中使用的"\n"。 10) 涉及HTML的文档，尽量使用XHTML1.0 transitional文件类型，其中所有HTML 标签都应关闭。 11) 在HTML、JavaScript、XML代码中，缩进应为两个空格，不得使用Tab。 12) HTML标签的name和id属性的命名方式应与Java变量名相同。 13) 在需要经常创建开销较大的对象时，开发人员应考虑使用对象池。 14) 在进行log的获取时开发人员应尽量使用isXXXEnabled。 15) log的生成环境上尽量避免输出文件名和行号。 16) 产品中不要包含后门代码，隔离系统中的后门代码，确保其不能出现在产品中。作 为一种特殊的调试代码，后门访问代码是为了使开发者和测试工程师访问一部分终 端用户不能访问的程序代码。但是，如果后门代码被留到产品中，对攻击者来说，它就是一条不需要通过正常安全手段来攻陷系统的通路。
分支定界法 分支定界法(branch and bound)是一种求解整数规划问题的最常用算法。这种方法不但可以求解纯整数规划，还可以求解混合整数规划问题。 基本信息 中文名称：分支定界法 外文名称：branch and bound 用途：整数规划问题 性质：算法 定义 分支定界法（branch and bound）是一种求解整数规划问题的最常用算法。这种方法不但可以求解纯整数规划，还可以求解混合整数规划问题。 算法步骤 第1步：放宽或取消原问题的某些约束条件，如求整数解的条件。如果这时求出的最优解是原问题的可行解，那么这个解就是原问题的最优解，计算结束。否则这个解的目标函数值是原问题的最优解的上界。 第2步：将放宽了某些约束条件的替代问题分成若干子问题，要求各子问题的解集合的并集要包含原问题的所有可行解，然后对每个子问题求最优解。这些子问题的最优解中的最优者若是原问题的可行解，则它就是原问题的最优解，计算结束。否则它的目标函数值就是原问题的一个新的上界。另外，各子问题的最优解中，若有原问题的可行解的，选这些可行解的最大目标函数值，它就是原问题的最优解的一个下界。 第3步：对最优解的目标函数值已小于这个下界的问题，其可行解中必无原问题的最优解，可以放弃。对最优解的目标函数值大于这个下界的子问题，都先保留下来，进入第4步。
第4步：在保留下的所有子问题中，选出最优解的目标函数值最大的一个，重复第1步和第2步。如果已经找到该子问题的最优可行解，那么其目标函数值与前面保留的其他问题在内的所有子问题的可行解中目标函数值最大者，将它作为新的下界，重复第3步，直到求出最优解。
开发规范文档版本 <1.0>
修订历史记录
目录 1. 前言5 1.1 目的5 1.2 概述5 2. 命名规范(Naming Conventions) 5 2.1 包命名6 2.2 类命名6 2.3 接口命名6 2.4 方法命名6 2.5 类成员参数7 2.6 局部变量7 2.7 常量7 2.8 集合7 2.9 魔法数字7 2.10 其他8 2.11 项目分层8 3. 代码排版规范9
3.1 空行9 3.2 空格9 3.3 大括号(Braces) 10 3.4 换行(New Lines) 10 3.5 长度(Length) 10 4. 声明10 4.1 类、接口10 4.2 方法10 4.3 字段11 5. 其他约束11 5.1 类成员可见性11 5.2 赋值(Assignment) 11 5.3 12 5.4 条件表达式使用12 5.5 无效语句12 5.6 Import 规范12 5.7 String比较13
5.8 注释要求13 5.9 Try if嵌套层次和分支复杂度14 5.10 Switch 语句14 6. 设计规范15 6.1 类与接口15 6.2 方法15 6.3 表达式与语句16 6.4 控制语句16 6.5 循环语句17 6.6 异常处理18
软件开发规范文档 1.前言 1.1目的 本规范的目的是使本组织能以标准的、规范的方式设计和编码。通过建立编码规范，以使每个开发人员养成良好的编码风格和习惯；并以此形成开发小组编码约定，提高程序的可靠性、可读性、可修改性、可维护性和一致性等，增进团队间的交流，并保证软件产品的质量。 1.2概述 对于代码，首要要求是它必须正确，能够按照设计预定功能去运行；第二是要求代码必须清晰易懂，使自己和其他的程序员能够很容易地理解代码所执行的功能等。然而，在实际开发中，每个程序员所写的代码却经常自成一套，很少统一，导致理解困难，影响团队的开发效率及系统的质量等。因此，一份完整并被严格执行的开发规范是非常必须的，特别是对软件公司的开发团队而言。 最根本的原则： 代码虽然是给机器运行的，但却是给人读的！ 2.命名规范(Naming Conventions) 命名规范使程序更易读，从而更易于理解。它们也可以提供一些有关标识符功能的信息，以助于理解代码，例如，不论它是一个常量，包，还是类。大家遵守一定的规范，相互看其他人的代码也会更加方便。 ?使用可以准确说明变量/字段/类/接口/包等的完整的英文描述符。例如，采用类似firstName，listAllUsers 或CorporateCustomer 这样的名字，尽量不使用汉语拼音及不相关单词命名，严禁使用汉语拼音首字母组合命名，虽然Java 支持