代码检查规范.docx
《代码检查规范.docx》由会员分享，可在线阅读，更多相关《代码检查规范.docx（15页珍藏版）》请在冰点文库上搜索。
代码检查规范
1前端HTML及JS页面检查
1）、性能考虑
1.IE中的CSS选择器（selector）运行缓慢，针对相同对象重复进行CSS查找，建议将第一次查找的结果保存到变量中，在以后需要的时候重用即可，不必再重复进行查找。
如varelement=$（“.shoppingcart”）。
2.任何情况下，页面控件都要定义一个id。
因为这样选择器会从一个相对末端的DOMNode开始，提高定位检索校验。
3.JavaScript和XmlHttpRequest是AJAX技术的基础，很多JavaScript框架都提供了非常方便的使用方法，Web开发人员会充分利用其异步通信优势来实现诸如分页加载等效果，避免对整个页面的操作。
通常这种方式被滥用了——过多的信息通过过多的调用来动态访问，例如，在一个显示10种商品的页面中，开发人员可能想分别加载每种商品的详细信息。
这意味着，你需要和服务器端进行10次交流才能得到全部信息，也会对后台系统产生压力。
建议，在这种情况下，把10次调用合并成1次来减少通信压力。
4.JavaScript文件过多带来两个问题：
一是浏览器在加载这些文件时需要通过JavaScript引擎切换上下文运行环境，二是因为下载文件而带来额外的网络通信。
解决方法，建议减少JavaScript文件数量。
2）、js代码规范
1.js文件命名，每个js文件与一个Html页面对应，内容包括该页面上的处理。
文件名与该Html页面名字相同，使用英文，首字母大写。
如：
页面为“View1.html”，那么与之对应的js文件则为“View1.js”。
这样方便查找文件，使程序结构清晰，易于代码维护。
2.文件结构，文件夹名使用英文，字母小写。
公用Js文件统一放到工程根目录的/js目录下，各模块/js子目录与之对应的html文件目录保持一致，即/js目录与html目录相对应。
目的为了便于文件的管理，避免所有js文件都在一个目录下，造成混乱。
3.建议采用面向对象方式进行javascript编码，如下两种常见方式：
（构造函数方式），封装比较好，但开销比较大
（构造函数/原型方式），封装不好，但开销比较少
4.在Javascript中，变量不是全局范围的就是函数范围的，使用"var"关键词将是保持变量简洁明了的关键。
当声明一个或者是全局或者是函数级（function-level）的变量，需总是前置"var"关键词。
5.采用Json方式，定义常量及各种词汇列表。
如
3）、JQuery代码规范
1、等价、不等价的使用
尽量使用严格的等价判断符===，尽量不用==；不等价判断符号!
==,不用!
=
3、字符串定义
关于js中定义字符串时，统一使用双引号，而非单引号。
varname=“xiaoming”;//正确
varname=‘xiaoming’;//错误
2后端Java代码检查
1）、性能考虑
1、尽量减少查询数据库次数，不要在循环中打开数据库。
2、查询数据参数维护类的数据时，使用配置了缓存的方法，从内存中取数据。
3、字符串拼接的时候，杜绝使用String+String+…,而是使用StringBuffer对象进行字符串对象拼接。
2）、设计考虑
1、设计六大原则，大家做设计是一定要经常对照一下，你的设计是否做了？
（当然原则是死，我们要灵活运用）
OCP（开闭原则，对扩展开放，对修改关闭，总原则）
OCP原则就是在不修改源代码的情况下，设计方案能适应于各种扩展的需求（当然这是最理想的情况）。
这是一个愿景性质的原则，如果系统能够达到OCP原则描述的情形就比较理想了，对扩展开放、对修改关闭，即，不修改原有代码即可完成对系统的扩展
OCP原则还可表述为“对可变性的封装”原则。
“找到一个系统的可变因素，将它封装起来。
”一个可变性因素，不应该被散落在各个角落，而应该被封装到一个对象中。
一种可变性因素，不应该与另一种可变性因素混和在一起，而应各自独立开。
做到OCP有两点：
抽象、对可变性封装。
单一职责原则（SRP）
一个类，应该只有一个职责。
每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。
这会导致脆弱的设计。
当一个职责发生变化时，可能会影响其它的职责。
另外，多个职责耦合在一起，会影响复用性。
我们可能只需要复用该类的某一个职责，但这个职责跟其它职责耦合在了一起，很难分离出来。
是接口一定要做到单一职责，类设计尽量只有一个原因引起变化
里氏代换原则（LSP）
任何基类可以出现的地方，子类一定可以出现（反过来不成立），用来指导我们如何去构建一个extends（继承、派生）结构。
子类与父类的关系必须是is-A，即，子类必须在任何场合都敢于大声宣称自己起码（至少）是一个父类。
比如，假设某类结构，“男人”、“女人”从“人”派生出来，看起来就是满足里氏代换原则的，因为无论“男人”还是“女人”，在任何场合都是“人”。
依赖倒换原则（DIP）
要依赖于抽象，不要依赖于具体实现。
DIP跟另一种说法含义相近：
面向接口编程。
具体地指导我们对抽象类（接口）、实现类的使用，依赖于抽象的实体（interface/abstractclass），才能够更具有可插入性（但凡实现既有接口的实现类实例都可以在依赖此接口的地方以此接口实例的角色插入进来），更容易满足OCP原则（抽象的层次不变化、实现的层次由于使用不同的类来封装不同的变化，于是可以在增加新类作为扩展的同时不需要修改已有实现类）。
接口隔离原则（ISP）
应当为客户端尽可能小的单独的接口，而不要提供大的总接口。
要求类之间的接口更加狭窄，更加确切、更加合身地封装变化。
比如，A/B接口可能在大多数情况下都由同一个实现类提供，但某些情况下，B接口都有些实现类是没有意义的，这时候就需要把A/B分开作为两个接口，某些类实现全部A/B接口、某些类仅实现A接口。
A/B单独变化，于是把A/B单独封装，接口隔离
合成/聚合复用原则（CARP）
要尽量使用合成/聚合，而不是继承关系达到目的。
复用角度来说：
“合成/聚合复用”比“继承”复用灵活。
前者是动态复用（因而具有可插入性）、后者是静态复用（编译时就固定了复用关系），而且后者的复用有“不支持多重继承”的限制
迪米特法则（LoD）
一个软件实体尽当尽可能少的与其他软件实体发生相互作用。
通俗讲只与你直接的朋友通信、不要跟“陌生人”说话，要求类之间的接口应该发生在哪些类之间，不应该发生在哪些类之间。
帮助我们解开类之间的耦合。
2、一个表，尽量只有一个Dao进行操作，其他需要进行访问的类，都应通过这个Dao进行操作。
3、一个类只有一个职责，功能职责过多需要考虑折分，一个方法一般只实现一个功能，职责清晰也方便代码复用。
3通用风格
1）、编辑规范
1、缩进，对齐
一个缩进，一个TAB键，默认TAB键4个半角字符
“{”括号起行，必须与“}”所在行对齐，处理在同一个缩进范围
2、包、类、属性、方法、变量、常量命名。
A.包，文件夹一律小写，最好英文单词；
B.类，文件首字母大写，多词时组合首字母大写，最好英文单词；
C.方法、变量首字母小写，多词时组合首字母大写，最好英文单词；
D.接口一般“I”前缀，数据库操作类一般“Dao”后缀，服务类一般“Service”后缀。
3、类，属性，方法的注释信息必须有，同时对注释有以下三点要求：
A.必须是有意义。
B.必须正确的描述了程序。
C.必须是最新的。
4、所有文件编码为UTF-8。
5、代码块书写规范
if/else/for/while/try要使用花括号，且要换行。
代码块一定要用花括号括起来：
if（true）//不提倡写法
alert（）;
If（true）{//提倡写法
alert（）;
}
2）、约定
1、对数据参数维护类模块，使用Hibernate操作数据库，其他模块采用JDBCTemplate。
2、要进行多个页面跳转或比较复杂的页面流程，可以采用struts2的Action，如维护页面的分页查询可以采用struts2的Action的方式。
其他一般的处理都要采用dwr的方式。
3、采用Hibernate注解，配置PO实体类。
PO实体类的属性一般与数据库表的列命名一致。
4、数据参数维护类模块，需要对相关方法进行Ehcache缓存处理，配置缓存拦截与失效方法。
5、日志分两大类，用户日志及系统日志，用户日志写入数据库，需要明确的信息记录前后变化，系统日志写入文件。
在Service层处理日志，用户日志记录增、删、改、审等变动，系统日志记录所有操作，包括查询及其他的处理中间过程。
5、错误信息在service处理，然后抛出到前台显示给用户，要精确明了。
其他层如Dao层只做抛出。
6、UserSession：
中可以只存放用户及权限信息，登陆信息。
其他公共对象，可以放在缓存中进行处理。
7、SVN提交代码要有详细的注释，主要说明提交的原因是修改什么东西，同时在群里跟大家说一下。
要养成早上上班更新svn的习惯，下班提交并更新svn。
2）、数据参数维护模块功能约定
1、数据参数维护类模块，按用户功能权限，对无权限的相关按钮必须置灰；只有满足相关条件才能正常显示控件按钮，比方说没有选择记录时，“删除”“修改”按钮都是灰色。
对于正在执行的按钮也同样置灰，执行完成后恢复。
2、如系统参数设置为“不启用审核”功能，则审核相关按钮不显示，默认维护数据是已审核，审核人就是维护人。
3、审核时要注意两个参数是否设置，“不能审核自己维护的数据”，“反审核和审核不能是同一个”。
4、参数设置可以分类进行维护：
比如交易数据处理的可以单独放在一块，凭证处理的放在一块等；也可以按业务来分比如ETF单独放在一块进行维护。
5、参数选项说明：
选项名称一定要简单明了，对于不能通过选项名称描述清楚的，可以给出一个详细的提示信息，比如鼠标放在上面时给出详细选项说明（一定要有勾选该选项代表什么意思，不勾选代表什么意思，默认是否勾选，是套帐专用还是公用等）。
6、查询显示列表必须按某种方式排序，未审核数据红色显示，鼠标选择某行记录蓝色显示。
7、双击列表可强显示记录详细信息，并且不可编辑，同时可能通过上一条下一条进行当前分页的浏览。
8、主键id采用自动增长类型，数据库设计18位长度，定义po类中的类型为Long类型。
9、可以进行多选操作，页面删除、审核、反审核都可以进行批量处理。
10、页面中如果元素很多（超过7个），要分主次按业务进行归类显示，次要的可以隐藏。
11、弹出子页面后或处理于一个长时间操作时，父页面要屏蔽（不能操作）。
12、套账列表用树显示在左边，右边显示元素。
13、检验控制
14、整体布局，行距，字体，控件摆放，
15、查询上下条目
16、ie11兼容（）
4数据库设计及SQL语句规范
1.每个数据表都要建立主键，对于数据维护类数据表，可建立ID主键，方便Hibernate操作。
2.Select语句不建义使用“*”，应列出全部列名查询。
3.Insert语句同样建义列出要插入的全部列名。
4.建议采用预处理PreparedStatement语句进行数据库的操作，特别是批量插入。
5.建议对SQL语句在类中，进行静态常量定义。
6.数据库一定要注意兼容，需要DB2，SQLServer，Oracle下都能执行。
7.对于数据量大的表需要建立索引，以便提高查询效率。
8.对大数据量表必须进行分区设计，分区表尽量使用Local的分区索引。
5附注OracleSQL的优化规则
【一】尽量少用IN操作符，基本上所有的IN操作符都可以用EXISTS代替
用IN写出来的SQL的优点是比较容易写及清晰易懂，但是用IN的SQL性能总是比较低的，从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别：
ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。
由此可见用IN的SQL至少多了一个转换的过程。
一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。
Oracle在执行IN子查询时，首先执行子查询，将查询结果放入临时表再执行主查询。
而EXIST则是首先检查主查询，然后运行子查询直到找到第一个匹配项。
NOTEXISTS比NOTIN效率稍高。
但具体在选择IN或EXIST操作时，要根据主子表数据量大小来具体考虑。
推荐方案：
在业务密集的SQL当中尽量不采用IN操作符。
【二】不用NOTIN操作符，可以用NOTEXISTS或者外连接+替代
此操作是强列推荐不使用的，因为它不能应用表的索引。
推荐方案：
用NOTEXISTS或（外连接+判断为空）方案代替
【三】不用“<>”或者“!
=”操作符。
对不等于操作符的处理会造成全表扫描，可以用“<”or“>”代替
不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。
推荐方案：
用其它相同功能的操作运算代替，如：
1）a<>0改为a>0ora<0
2）a<>’’改为a>’’
【四】Where子句中出现ISNULL或者ISNOTNULL时，Oracle会停止使用索引而执行全表扫描。
可以考虑在设计表时，对索引列设置为NOTNULL。
这样就可以用其他操作来取代判断NULL的操作
ISNULL或ISNOTNULL操作（判断字段是否为空）
判断字段是否为空一般是不会应用索引的，因为B树索引是不索引空值的。
推荐方案：
用其它相同功能的操作运算代替，如：
1）aisnotnull改为a>0或a>’’等。
2）不允许字段为空，而用一个缺省值代替空值，如业扩申请中状态字段不允许为空，缺省为申请。
3）建立位图索引（有分区的表不能建，位图索引比较难控制，如字段值太多索引会使性能下降，多人更新操作会增加数据块锁的现象）
【五】当通配符“%”或者“_”作为查询字符串的第一个字符时，索引不会被使用
【六】对于有连接的列“||”，最后一个连接列索引会无效。
尽量避免连接，可以分开连接或者使用不作用在列上的函数替代。
【七】如果索引不是基于函数的，那么当在Where子句中对索引列使用函数时，索引不再起作用。
【八】Where子句中避免在索引列上使用计算，否则将导致索引失效而进行全表扫描。
【九】对数据类型不同的列进行比较时，会使索引失效。
【十】>及<操作符（大于或小于操作符）
大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。
那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时ORACLE会先找出为2的记录索引再进行比较，而A>=3时ORACLE则直接找到=3的记录索引。
推荐方案：
用“>=”替代“>”。
【十一】UNION操作符
UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。
实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION。
如：
select*fromgc_dfys
union
select*fromls_jg_dfys
这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。
推荐方案：
采用UNIONALL操作符替代UNION，因为UNIONALL操作只是简单的将两个结果合并后就返回。
select*fromgc_dfys
unionall
select*fromls_jg_dfys
【十二】LIKE操作符
LIKE操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，如LIKE‘%5400%’这种查询不会引用索引，而LIKE‘X5400%’则会引用范围索引。
一个实际例子：
用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号YY_BHLIKE‘%5400%’这个条件会产生全表扫描，如果改成YY_BHLIKE’X5400%’ORYY_BHLIKE’B5400%’则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高。
【十三】SQL书写的影响（共享SQL语句可以提高操作效率）
同一功能同一性能不同写法SQL的影响
如一个SQL在A程序员写的为
Select*fromzl_yhjbqk
B程序员写的为
Select*fromdlyx.zl_yhjbqk（带表所有者的前缀）
C程序员写的为
Select*fromDLYX.ZLYHJBQK（大写表名）
D程序员写的为
Select* fromDLYX.ZLYHJBQK（中间多了空格）
以上四个SQL在ORACLE分析整理之后产生的结果及执行的时间是一样的，但是从ORACLE共享内存SGA的原理，可以得出ORACLE对每个SQL都会对其进行一次分析，并且占用共享内存，如果将SQL的字符串及格式写得完全相同则ORACLE只会分析一次，共享内存也只会留下一次的分析结果，这不仅可以减少分析SQL的时间，而且可以减少共享内存重复的信息，ORACLE也可以准确统计SQL的执行频率。
推荐方案：
不同区域出现的相同的Sql语句，要保证查询字符完全相同，以利用SGA共享池，防止相同的Sql语句被多次分析。
【十四】WHERE后面的条件顺序影响
Oracle从下到上处理Where子句中多个查询条件，所以表连接语句应写在其他Where条件前，可以过滤掉最大数量记录的条件必须写在Where子句的末尾。
WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响，如
Select*fromzl_yhjbqkwheredy_dj='1KV以下'andxh_bz=1
Select*fromzl_yhjbqkwherexh_bz=1 anddy_dj='1KV以下'
以上两个SQL中dy_dj（电压等级）及xh_bz（销户标志）两个字段都没进行索引，所以执行的时候都是全表扫描，第一条SQL的dy_dj='1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。
【十五】查询表顺序的影响
Oracle从右到左处理From子句中的表名，所以在From子句中包含多个表的情况下，将记录最少的表放在最后。
（只在采用RBO优化时有效）
在FROM后面的表中的列表顺序会对SQL执行性能影响，在没有索引及ORACLE没有对表进行统计分析的情况下ORACLE会按表出现的顺序进行链接，由此因为表的顺序不对会产生十分耗服务器资源的数据交叉。
（注：
如果对表进行了统计分析，ORACLE会自动先进小表的链接，再进行大表的链接）。
【十六】OrderBy语句中的非索引列会降低性能，可以通过添加索引的方式处理。
严格控制在OrderBy语句中使用表达式
【十七】当在Sql语句中连接多个表时，使用表的别名，并将之作为每列的前缀。
这样可以减少解析时间
多利用内部函数提高Sql效率
SQL语句索引的利用
对操作符的优化（见前面）
对条件字段的一些优化
采用函数处理的字段不能利用索引
如：
substr（hbs_bh,1,4）=’5400’，优化处理：
hbs_bhlike‘5400%’
trunc（sk_rq）=trunc（sysdate），优化处理：
sk_rq>=trunc（sysdate）andsk_rq进行了显式或隐式的运算的字段不能进行索引
如：
ss_df+20>50，优化处理：
ss_df>30
‘X’||hbs_bh>’X5400021452’，优化处理：
hbs_bh>’5400021542’
sk_rq+5=sysdate，优化处理：
sk_rq=sysdate-5
hbs_bh=5401002554，优化处理：
hbs_bh=’5401002554’，注：
此条件对hbs_bh进行隐式的to_number转换，因为hbs_bh字段是字符型。
【十八】条件内包括了多个本表的字段运算时不能进行索引
ys_df>cx_df，无法进行优化
qc_bh||kh_bh=’5400250000’，优化处理：
qc_bh=’5400’andkh_bh=’250000’
升级会员 