java代码走查审查规范

分类 重要性 检查项 备注
命名      
  重要 命名规则是否与所采用的规范保持一致? 成员变量,方法参数等需要使用首字母小写,其余单词首字母大写的命名方式,禁止使用下划线(_)数字等方式命名
不要出现局部变量,成员变量大写字母开头等问题
  一般 是否遵循了最小长度最多信息原则? 各种命名尽可能短,表意准确,除2代替‘to’,4代替‘for’外,不建议使用数字在命名中
  重要 has/can/is前缀的函数是否返回布尔型? 成员变量,方法参数,局部变量等为布尔型时,如果出现has/can/is开头,则将这些词去掉
  重要 类名是否存在重名问题? 自己实现的类尽量不要和别人的类重名,尽管不在同一个包下,特别是子类和父类重名的情况
注释      
  重要 注释是否较清晰且必要? 方法JAVADOC注释中需要说明各参数、返回值及异常说明,参数说明需按照参数名称及用意对应标注
  重要 复杂的分支流程是否已经被注释?  
  一般 距离较远的}是否已经被注释?  
  重要 函数是否已经有文档注释?(功能、输入、返回及其他可选) 文件,类(含接口,枚举等),成员变量,方法前需要有JAVADOC的注释
  一般 特殊用法是否被注释?  
声明、空白、缩进      
  一般 每行是否只声明了一个变量?(特别是那些可能出错的类型)  
  重要 变量是否已经在定义的同时初始化?  
  重要 类属性是否都执行了初始化?  
  一般 代码段落是否被合适地以空行分隔?  
  一般 是否合理地使用了空格使程序更清晰? 基本代码格式中的空格符不可缺少,这些空格出现在?,:,+,-,*,/,=,==,>,<,>=,<=,!=,及各种括号附近
  提示 代码行长度是否在要求之内? 每行不得超过120个字符
  重要 controller,service, dao 中不要声明有状态的变量。 此变量不能被修改。如果要进行修改,必须通过锁进行控制。
  一般 折行是否恰当?  
  一般 集合是否被定义为泛型类型? 定义集合时,建议定义其泛型类型,减少类型转换和警告错误
语句/功能分布/规模      
  一般 包含复合语句的{}是否成对出现并符合规范?  
  重要 是否给单个的循环、条件语句也加了{}? if,else,else if,while,for,case等代码块必须用{}包围
  一般 单个变量是否只做单个用途?  
  重要 单行是否只有单个功能?(不要使用;进行多行合并)  
  重要 单个函数是否执行了单个功能并与其命名相符?  
  一般 操作符++和— —操作符的应用是否符合规范?  
规模      
  重要 单个函数不超过规定行数?  
  重要 缩进层数是否不超过规定?  
可靠性(总则/变量和语句)      
  重要 是否已经消除了所有警告? 开发工具的警告
  重要 常数变量是否声明为final?  
  重要 对象使用前是否进行了检查?  
  重要 成员变量,局部变量是否在使用前被赋值? 对象初始化为null的对象被调用前必须被重新赋值,如果赋值语句在try块中,调用操作必须在try块中
  一般 局部对象变量使用后是否被复位为NULL? 特别是 数组 集合 Map
  重要 对数组的访问是否是安全的?(合法的index取值为[0, MAX_SIZE-1])。  
  重要 是否确认没有同名变量局部重复定义问题? 严禁局部变量名称和类或对象成员变量同名
  一般 程序中是否只使用了简单的表达式?  
  重要 是否已经用()使操作符优先级明确化?  
  重要 所有判断是否都使用了(常量==变量 或者 常量.equals(变量))的形式? 常量放在比较符前可以有效降低比较符写成赋值语句 ,减少空指针异常
  重要 是否每个if-else if-else语句都有最后一个else以确保处理了全集?  
  重要 是否每个switch-case语句都有最后一个default以确保处理了全集?  
  一般 for循环是否都使用了包含下限不包含上限的形式?(k=0; k<MAX)  
  重要 XML标记书写是否完整,字符串的拼写是否正确?  
  重要 对于流操作代码的异常捕获是否有finally操作以关闭流对象? 关闭前需要判断 流对象是否为空 
  提示 退出代码段时是否对临时对象做了释放处理?  
  重要 对浮点数值的相等判断是否是恰当的? 严禁使用==直接判断浮点数值 。提供通用方法
  重要 是否对象比较都使用了equals? 对象(包括包装类)比较必须使用equals,而不是使用==或!=操作
  重要 使用equals进行比较时是否确保比较的两个对象类型一致? equals方法比较的对象在对象类型确定的前提下,建议是同一类型的,例如Integer和""使用equals是不提倡的
  一般 操作Map或Properties结构对象,用于传值时是否将Key定义为常量? Session,Request等对象的setAttribute,getAttribute方法的key建议使用常量,不得手工输入字符串
  重要 是否在类型转换前确保了类型的兼容? 除非明确保证对象类型
  重要 包装类做简单预算前是否保证非空? 建议都使用包装类。 包装类进行操作前,建议进行非空(null != xx)判断,防止发生空指针异常
  重要 对象属性在使用前是否确保被准确赋值? 只读属性(只提供get方法的成员变量)除非特意返回固定值,否则必须提供set方法或在其他方法调用时将其赋值
  重要 方法调用前是否有非空判断? 对参数的非空判断必须出现在方法调用之前,否则说明前面可能导致空指针或者后者判断是没有必要的,非空判断,默认由调用者提供
  重要 非线程安全的对象是否被正确保证线程安全? DateFormat实例的format方法调用不是线程安全,类似的情况不适合使用static定义,建议使用ThreadLocal方式实现,参看UnifiedCodeGenerator
  一般 相同用意的成员变量是否使用了相同的命名? 不同实体Entity、VO、BO之间表示同一含义的成员变量,建议使用相同的名称,尽量不要出现,有的地方用username,有的地方用userName这样的情况
可靠性(函数)      
  重要 入口对象是否都被进行了判断不为空?  
  重要 入口数据的合法范围是否都被进行了判断?  
  重要 是否对有异常抛出的方法都执行了try...catch保护?  
  重要 是否函数的所有分支都有返回值?  
  重要 int的返回值是否合理?(负值为失败,非负值成功)  
  一般 对于反复进行了int返回值判断是否定义了函数来处理?  
  一般 关键代码是否做了捕获异常处理?  
  一般 字典表定义是否用枚举,或者有一个统一的定义?  
  重要 是否对方法返回值对象做了null检查,该返回值定义时是否被初始化?  
  重要 是否对同步对象的遍历访问做了代码同步?  
  重要 是否确认在对Map对象使用迭代遍历过程中没有做增减元素操作? Map遍历时执行增减元素操作将抛出ConcurrentModificationException,对集合对象遍历时建议都不要进行增减元素操作。
  重要 线程处理函数循环内部是否有异常捕获处理,防止线程抛出异常而退出?  
  重要 原子操作代码异常中断,使用的相关外部变量是否恢复先前状态?  
  重要 函数对错误的处理是恰当的?  
  重要 异常捕获后是否进行了日志记录或异常继续抛出? 异常捕获后如果无法处理需要继续抛出,如果可以处理,建议将异常日志进行记录
  重要 是否构造方法中不调用当前对象的构造方法 严禁在构造方法中new一个当前对象
可维护性      
  重要 实现代码中是否消除了直接常数?(用于计数起点的简单常数例外)  
  重要 是否消除了导致结构模糊的连续赋值?(如a= (b=d+c ))  
  重要 是否正确使用了日志记录?  
  一般 是否有冗余判断语句?(如:if (b) return true; else return false;) “if (b) return true; else return false;”==》“return b;”;禁止使用类似“if/while(表达式 == true)或if/while(表达式 == false)”的判断
  重要 是否把方法中的重复代码抽象成私有函数?  
代码警告      
  一般 是否清除了多余导入的包或类?  
  重要 是否清除了只定义未使用的局部变量? 严禁局部变量被定义或者初始化而未被使用,这种情况需要删除该局部变量
  一般 是否将魔鬼数字修改为常量使用? 不允许直接使用除-2,-1,0,1,2,3,4,5,6,7,8,9,10外的数字,除此外的数字需要定义常量使用
  提示 常量定义是否为static final格式? 常量定义格式为public/protected//private static final Type TYPE,static和final顺序要保持一致
  提示 实现序列化的对象是否定义了serialVersionUID? 建议实现Serializable的类需要增加“private static final long serialVersionUID = 1L;”
可读性      
  一般 是否用if else结构替换了三元运算符? 表达式复杂情况下 不要使用(flag?exp1:exp2)语句,该语句需要修改为if else结构
  一般 代码注释率是否结余30%~60%之间? 代码注释率应落在30%~60%之间
性能      
  重要 日志记录的Log,Logger对象是否定义为常量? 用于记录日志的Log,Logger对象在类中定义必须是static final的,建议定义为private的,因为这类对象初始化比较耗时,不利系统运行
日志      
  重要 打印信息是否都用日志管理? 代码中建议不要使用System.out.println打印信息,只有在系统启动或系统即将退出时使用,其余部分全部用日志记录
圈复杂度      
  重要 单个类行数是否不大于500行? 单个类建议行数小于500行,最多不超过1000行
  重要 方法参数个数是否在7个以内? 方法参数个数建议不大于5个,最多不超过7个
  重要 单个方法函数是否不大于30行? 单个方法建议函数不大于30行,做多不超过60行
  重要 单方法中try/for/while/switch/if最深深度是否不大于5? 单方法中try/for/while/switch/if最深深度不允许大于5
  重要 方法调用最深深度是否不大于15? 方法内部+内部调用累计深度不允许大于15
SQL空格      
  一般 连接符or、in、and、以及=、<=、>=等前后加上一个空格。  
  一般 逗号之后必须接一个空格。  
  一般 关键字、保留字和左括号之间必须有一个空格。  
SQL注释      
  重要 对较为复杂的SQL语句加上注释,说明算法、功能。注释风格:注释单独成行、放在语句前面。  
  重要 对重要的计算应说明其功能。 SQL中尽量少涉及业务逻辑
  一般 可采用单行/多行注释。(-- 或 /* */方式)。  
SQL优化性能建议      
    1 书写SQL语句优化细则  
  重要    1) 尽量避免相同语句由于书写格式的不同,而导致多次语法分析。  
  重要    2) 多表连接时,使用表的别名来引用列。 建议最多5个连接
  重要    3) 不要在任何代码中使用 SELECT *。  
  重要    4) where条件中尽量减少使用常量比较,改用参数变量。  
  重要    5) 尽量少用嵌套查询。如必须,请用not exist代替not in子句。  
  重要    6) 用多表连接代替EXISTS子句。  
  重要    7) 使用UNION ALL提高性能 。  
  重要    8) in、or子句常会使用工作表,使索引失效;如果不产生大量重复值,可以考虑把子句拆开;拆开的子句中应该包含索引。  
    2 排序注意事项  
  重要    1) 大量的排序操作影响系统性能,所以尽量减少orderby和group by排序操作。如必须使用排序操作,请遵循如下规则:  
  重要      a. 排序尽量建立在有索引的列上。  
  重要      b. 如结果集不需唯一,使用union all代替union。  
    3 选用索引注意事项  
  重要    1) 对于复合索引,SQL语句必须使用主索引列。  
  重要    2) 索引中,尽量避免使用NULL。  
  重要    3) 对于索引的比较,尽量避免使用NOT=(!=)。  
  重要    4) 查询列和排序列与索引列次序保持一致。  
    4 其他经验性规则  
  重要    1) 任何对列的操作都将导致表扫描,它包括数据库函数、计算表达式等等,查询时要尽可能将操作移至等号右边。  
时间: 2024-10-10 09:55:50

java代码走查审查规范的相关文章

java开发命名规范(转载)

java开发命名规范 使用前注意事项: 1.  由于Java面向对象编程的特性, 在命名时应尽量选择名词 2.  驼峰命名法(Camel-Case): 当变量名或函式名是由一个或多个单字连结在一起,而构成的唯一识别字时,首字母以小写开头,每个单词首字母大写(第一个单词除外). 如:myFirstName 一 包名的书写规范 (Package) 推荐使用公司或机构的顶级域名为包名的前缀,目的是保证各公司/机构内所使用的包名的唯一性.包名全部为小写字母,且具有实际的区分意义. 1.1 一般要求 1.

Java的命名规范(转载)

Java是一种区分字母的大小写(case-sensitive)的语言,下面谈谈Java语言中包.类.变量等的命名规范. (一)Package(包)的命名: Package的名字应该都是由一个小写单词组成,例如net.ebseries.modules. (二)Class(类)的命名: Class的名字首字母大写,通常由多个单词合成一个类名,要求每个单词的首字母也要大写,例如:DataFile或InfoParser. (三)变量的命名: 变量的名字可大小写混用,但首字符应小写.词由大写字母分隔,限制

Java Script 编码规范

Java Script 编码规范 以下文档大多来自: Google JavaScript 编码规范指南 Idiomatic 风格 参考规范 ECMAScript 5.1 注解版 EcmaScript 语言规范, 5.1 版 基本原则: 无论有多少人在维护,所有在代码仓库中的代码理应看起来像同一个人写的. 前言 下面的章节描述的是一个 合理 的现代 JavaScript 开发风格指南,并非硬性规定.其想送出的核心理念是高度统一的代码风格(the law of code style consiste

Java项目命名规范(简洁版)——高薪必看

作为一个优秀的项目经理或项目带头人,必须养成良好优秀的项目命名规则和习惯.接下来把查到的资料整理一下,实际上,在很多项目中,也是遵循以下的规则. 一.项目名 全部小写,比如cms.workdesk,jobserver等 二.java相关命名 a.类命名:每音节单词前的第一个字母大写,比如FieldInfo.Expression等\ b.普通变量(包括spring里的变量引用命名):第一个单词前小写,以后每个单词第一个字母大写,password,primaryFlag c.静态变量:全部大写,多个

Java编程风格规范(Google )

Google Java编程风格指南 前言 这份文档是Google Java编程风格规范的完整定义.当且仅当一个Java源文件符合此文档中的规则, 我们才认为它符合Google的Java编程风格. 与其它的编程风格指南一样,这里所讨论的不仅仅是编码格式美不美观的问题, 同时也讨论一些约定及编码标准.然而,这份文档主要侧重于我们所普遍遵循的规则, 对于那些不是明确强制要求的,我们尽量避免提供意见. 1.1 术语说明 在本文档中,除非另有说明: 术语class可表示一个普通类,枚举类,接口或是anno

Java安全编码规范

SQL Injectioin防范 ibatis框架先看一段ibatis的xml配置 <select id="queryByAccountId" parameterClass="java.util.Map" resultMap="ApplicationInstanceResult">     SELECT * FROM product where account_id = $accountId$ </select> 以上的s

Java代码格式化规范实践总结

目标说明 统一良好的代码格式规范可以有效提升开发团队之间的「协作效率」,如果不同的开发团队或者开发人员采用不同的代码格式规范,那么每次Format代码都会导致大量的变化,在Code Review及Merge代码时会带来很多的干扰项.因此制定本代码规范希望达成以下目标: 统一Java代码格式规范,确保团队成员间「代码风格一致」: 保证Format代码时不会引入格式上的干扰: 提升团队协作效率.Code Review效率: 怎么实施 在Java代码规范方面目前Google Java Code Sty

Java学习---Java代码编写规范

编码规范 1 前言为确保系统源程序可读性,从而增强系统可维护性,java编程人员应具有基本类似的编程风格,兹制定下述Java编程规范,以规范系统Java部分编程.系统继承的其它资源中的源程序也应按此规范作相应修改. 2 适用范围本文档将作为java编程人员软件开发的编程格式规范.在项目Java部分的编码.测试及维护过程中,要求严格遵守. 3 命名规范定义这个规范的目的是让项目中所有的文档都看起来像一个人写的,增加可读性,减少项目组中因为换人而带来的损失. 3.1 Package 的命名Packa

Java权威编码规范

一.编程规约 (一) 命名规约 1. [强制] 代码中的命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束. 反例: _nam / __name / $Object / name_  / name$ / Object$2. [强制] 代码中的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式. 说明:正确的英文拼写和语法可以让阅读者易于理解,避免歧义.注意,即使纯拼音命名方式也要避免采用. 反例: DaZhePromotion [打折] / getPingfenByName