Siebel实施规范-编码规范

1、 Siebel实施规范 编码规范编写人: 张远舟日 期：2010-7-5目 录一、简介11. 目的12. 适用范围1二、编程规范11. 总体规范12. 代码格式规范13代码注释规范14. 命名规范35. 逻辑稳定规范45. 性能效率规范4三、 代码Review规范51. 代码Review的目的52. 代码Review方法53. 代码Review规范5一、简介1. 目的本文的目的在于为汉得Siebel技术团队的编码规范提出意见和参考。2. 适用范围本规范（草稿）应用于Siebel实施项目中使用E-Script进行的编码的脚本开发。二、编程规范1. 总体规范【规范1】优先考虑编码的可替代方案(Us

2、er Property, Model State, Validation等)【规范2】时刻考虑到你的每一个编码都会由其他的人在其他的时间使用、维护、增强【规范3】以不懂程序的人都能读懂你的代码为编码的最基本目标和要求【规范4】尽量使你的程序容易被调用（重用），修改和扩展【规范5】合理地捕获和处理异常【规范5】新创建的对象需要在代码结束时显式释放【规范6】效率是永远需要重点考虑、分析和优化的问题点【规范7】把相关的逻辑封装在BS中，避免代码分散冗余，增加维护成本2. 代码格式规范【规范1】单行代码不得太长，需便于阅读，太长的代码行需要在适合的位置断行【规范2】每行代码最多包含一个独立的语句。【规

3、范3】代码块之间使用Tab缩进一次【规范4】一个方法的代码语句不宜过多，复杂的逻辑使用拆分成几个独立的Function来实现，并确保一个Function只做一件独立的事情。【规范5】每一个变量的声明独占一行，变量的声明置于代码块开始位置。【规范6】在逻辑块、代码块之间合理使用单个空行3代码注释规范【规范1】适当地编写代码注释，增强代码的可读性和可维护性说明：一般情况下，程序或Function的作用，参数，创建和修改信息等都需要通过注释来标识，便以使用、维护和管理。程序中的逻辑块、复杂算法、重要变量的意义等也需要用注释来说明。【规范2】在修改代码的同时，修改代码注释。说明：代码被修改后，必须同步

4、修改代码注释，已实现注释的正确指导意义。代码频繁被改动但注释不变是容易导致歧义的根源之一。【规范3】注释必须有但是不能过度。并不需要为每一句代码、每一个变量使用一句注释，这样反而使得代码变得冗长累赘而不易维护。一般只在关键点使用注释。【规范4】方法注释规范。方法注释用于说明方法文件的一些基本信息，包括方法的作用，参数，返回值，创建者和创建日期，更新者和更新日期，代码版本等。如对Function SubmitOrder(orderId)注释如下：/* * Function: To Set The Status of The Specified Order to Be Submitted * Pa

5、ram1 orderId: The Id Value of The Specified Order * Return: true if success, otherwise false * Author：Neo.Zhang * Created： 6/10/2010 * Last Updated By：Neo.Zhang * Last Updated: 7/5/2010 * Modifications:* 1. Add Validation to Make Sure Order Type Is Purchase Order on 6/12/2010 By Neo.Zhang* 2. Commen

6、ted the Code Block of Purchase History Accumulation on 7/5/2010 By Neo.Zhang* Version: 1.2 */注释可根据项目环境选择使用中文或英文。【规范5】变量注释规范 以下情况，变量需要使用注释：1. 常量，尤其是业务常量2. 采用了不容易被理解的缩写作为变量名的变量3. 程序逻辑中重要的核心变量4. 作为方法返回值的变量5. 变量注释的格式为在变量声明的上一行使用/注释如:/A Dictionary Array to Store Order Quantity of Product Idvar aProdQty =

7、 ;【规范6】不要编写修饰性的注释。不要使用类似以下的注释。因为脚本具有最大字节数限制，这样的注释将占用大量字节数，且显得累赘多余。/* * This Code Block Deals With the RMA Business*/ 【规范7】在具有复杂算法或复杂逻辑的代码块前，说明其算法或逻辑。例如：/* 以下的代码用于计算维修店计划建议表数据，具体逻辑是* */【规范8】对于临时代码或弃用代码，需要注释掉并说明注释原因，不可直接删除。临时代码是指现在不使用，但是将来有可能被启用的代码。弃用代码是指原来使用，但是现在不再使用的代码。对于这样的代码，我们通常使用/*/把它们注释起来，并在代码块

8、上一行说明注释原因，如： 临时代码注释说明：/修改SO行数量时，连带修改相应的PO行数量。在直发业务流程启用后开始使用/* Code*/弃用代码注释说明：/经业务方确认，网点提交订单时不再累计采购量/* Code*/【规范9】尽量使你的注释简单。注释只要能起到帮助清晰理解代码的意义即可，不需要字字句句都写得完整。【规范10】建议在编写代码之前就编写好你的注释。编写注释除了能提高代码可读性外，也是指导代码编写，帮助理清思路的好方法，因此尽量养成编码前编写代码而不是编码后写注释的习惯。4. 命名规范【规范1】必须慎重地、认真地为你的每一个BS、方法、变量命名。说明：要起一个科学合理的名字，因为名字

9、是理解代码的重要依据。同时，使用统一规范的命名格式将使系统风格更加统一。且一旦代码发布，即不可再随意更改，其依赖者、继承者都要永远维持这种命名。因此一次性命名规范准确具有重要意义。【规范2】使用英文习惯表达方式命名。说明：英文是全世界软件业通用的交流语言。【规范4】采用有意义的单词和短语作为方法、变量名，要求望文知意。【规范5】合理谨慎地使用缩写。【规范6】变量命名规范 说明：一般情况下，变量根据变量类型，带一个相应的前缀(常用类型可忽略)，后面跟着变量定义的英文描述，首字母小写，其它单词首字母大写。以下是各自变量类型的命名规范和示例。类型前缀示例 Stringnonevar orderSta

10、tus;var errMsg;var message;Integeri or nonevar iCount;(常用于计数变量)var qtyTotal;(用于业务变量)Numbern or nonevar nAmount; (常用于计算结果存放)var orderAmount; (用于业务变量)Date/Timed/tvar dDate;var tCurrentTime;Booleanbvar bRecordFound;User Defined Objectovar oMyObject = new Object;oMyO = My Defined Object;oMyObj

11、ect.description = This is My Object;BObovar boOrder;BCbcvar bcOrder;BSbsvar bsDropShip;Property Setpsvar psInput;Arrayavar aProduct = ;【规范7】常量命名规范说明：常量是指程序中值固定，不会在程序中被修改的量，譬如值列表、业务常数等。此类变量的命名规范是：全部字母大写，单词与单词之间用下划线分隔。例如： var STATUS_NEW = TheApplication().InvokeMethod(LookupValue,FS_ORDER_STATUS,New);

12、 var MAX_LINES_LTD = 1000; /此类业务常量一定要在代码开始的地方声明，不可直接用数字替代 常量一般在代码块最开始的地方声明，程序中不能有修改这些变量的语句。 尽量避免业务常量的使用，建议将业务常量作为参数维护在系统当中。【规范8】方法名命名规范方法名命名规范与代码相类似，但方法名的首字母需大写，且不需要前缀。一般情况下，方法名以动词开头，譬如：Function SubmitOrder(orderId);Function CreateAsset(searilId, assetNum, productId);5. 逻辑稳定规范【规范1】代码中尽量避免使用硬编码【规范2】对

13、象变量声明以后，必须在程序结束时释放【规范3】限制循环嵌套的层数，避免效率问题和死循环问题【规范4】值列表，尤其是动态值列表字段的设值需要使用Pick方法【规范5】尽量避免使用全局变量，尤其是Application层的全局变量【规范6】禁止混用SetSearchSpec和SetSearchExpr【规范7】使用SetSearchSpec方法时，需确保条件值不为空【规范8】尽量避免使用Browser Script，禁止使用Browser Script进行业务数据操作 说明：只允许在Applet层使用Browser Script，通常用于操作确认、提示等基本功能。【规范9】代码中进行数字计算和比较

14、时，需确保变量的类型为数值型【规范10】代码中需要正确地捕获和处理异常（trycatch(e)finally）【规范11】方法的参数数量限制在6个以内规范12 在做数据查询的时候要考虑ViewMode，程序结束时也需要考虑ViewMode的重置。说明：参数过多将容易导致参数传递错误，且不易于维护和理解。5. 性能效率规范【规范1】代码中尽量减少查询次数【规范2】尽量避免大表大范围数据扫描【规范3】必要时采用适当的算法提高代码执行效率【规范4】在需要作为查询条件的字段上建立索引【规范5】必要时使用数据库View，Function，Package等方式改进性能，但不可滥用【规范6】尽量避免使用代码三、 代码Review规范1. 代码Review的目的w 确保代码的正确性和可用性。w 确保编码符合规范。w 尽早发现和处理错误和风险。w 提供项目成员之间相互学习和交流的平台。2. 代码Review方法w 顾问之间交叉Review，确保自身写的代码由另外的技术顾问来做Revieww 从编码命名、格式规范、逻辑正确性和严密性、可扩展性及效率等多个方面进行分析w 个人单独Review，并编写开发编码Review报告w 根据报告，项目小组内共同讨论，确认是否存在改进的需要w 确认需要改进的代码，由开发者负责修改并重新