Java一些编码规则

有很多条， 是有经过教训得到。From：http://blog.sina.com.cn/s/blog_5465f7f20100tuv7.html

 

是否符合代码格式化标准 －－大规模开发， 造成代码合并问题， 使用统一格式规范
是否有多余的import项－－没有必要把一些不需要使用的代码引入， 并且方便阅读代码
是否定义了多余的field
是否定义了多余的本地变量
是否定义了多余的私有方法
是否有可以重构的逻辑重复的代码－－减少重复代码
方法／成员的public/private/static/final属性是否合理 －－封装API时候特别重要， 不因该暴露的东西被人使用， 后果很麻烦， 特别是升级的时候。
调用静态常量是否使用类／接口名
是否所有实现了java.io.Serializable接口的类都有serialVersionUID－－序列化版本控制用的。调整这个ID， 也可以使得CACHE序列化对象马上失效。用处大大的。
类／接口／变量／参数名，命名是否规范
所有的if,for,while块内容是否都用{}－－这个避免后来人修改代码出错。
是否有功能复杂的语句－－可读性／美观第一
将url，文件路径等写死在程序里（硬编码）－－多平台开发测试的问题很严重。一定不能写死
将中文写在程序里－－web程序中文写程序必要不
系统中使用到的非描述性字符串是否使用常量
系统中使用到的数字是否使用常量
常量是否有详细的注释
程序中是否存在System.out,System.err及Throwable.printStackTrace()－－这个问题最需要避免， 可能导致日志文件超级庞大， 无法控制其行为，最后导致应用关闭， 通常我们的日志文件配置不做控制台输出截获的配置。
系统中打开的流／文件／连接等是否保证能正常并及时关闭－－资源泄露问题， 导致文件描述符不够用。
在输出日志时，低级别的输出一定要判断isXXEnabled－－－性能问题， 避免很多string 连接的操作。
在生产环境中输出大量调试日志－－－日志归档过于庞大，性能低下
注意使用对象的线程安全
大规模的string组装－－－JAVA5版本及之前的都要注意
递归方法的使用－－－尽量避免， 减少栈的使用， 可能导致栈溢出
本地线程对象是否导致memory leak－－ ThreadLocal 必须定义成static， 就是引用他的类是singleton也要这么定义， 防止内存大规模泄露
应用代码中严格禁止硬转 编码，只能在框架里做统一的处理 －－编码效率低下的行为
是否编译过正则表达式,是否有大规模的表达式－－那些把正则当宝贝的行为要控制自己的使用频率， 以及主义表达式规模的问题
在出错路径上是否所有的资源（数据库连接，文件锁等）和引用都已经释放 －－资源泄露问题
在保证线程安全的同时，要注意避免过度使用同步，导致性能降低－－高并发的场景下， 合理利用每个LOCK， 除非万不得已， 不能以一个lock完成整个复杂函数操作。
同步对象上的锁是否按相同的顺序获得和释放以避免死锁，注意错误处理代码 －－导致应用挂起的罪魁祸首
所有的循环是否优化 ， 循环里操数据库或者其他数据源。
如果调用了阻塞方法，是否考虑了保证性能的措施－－注意响应性能问题
方法（函数）方面检查安全