命名规则:
1.不用特殊符号(¥,$,_等)开头或者结尾(无论对于函数名,类名还是变量名)
2.使用大写驼峰对应函数名和类名
3.使用小写驼峰对应变量名
4.使用全大写对应常量名,单词间用下划线(_)连接
5.抽象类类名使用Base或者Abstract开头
6.测试类类名使用Test作为结尾
7.数组的中括号紧接着类型后面
8.包名/命名空间名称使用小写
9.使用完整英文单词解析名称用途,不适用中文,中文拼音或者不完整英文单词来命名
10.如果类或者方法对应使用了某种设计模式,那么类名/方法名中最好体现该设计模式的名称
代码格式:
1.左大括号前面不换行,后面换行,右大括号后面如果有else则不换行,否则换行
2.if/for/while/switch/do以及注释(//)等关键字与后面的括号之间保留一个字节的空格
3.二目,三目运算符前后加空格
4.缩进使用4个空格
5.每一行代码不超过120个字符长度
6.方法总行数不超过80行
OOP编程规约:
1.构造方法中禁止加入业务逻辑代码
2.业务类最好实现toString方法,用于运行时输出状态或者IDE调试
3.类中定义方法的顺序应该是 公有 > 保护 > 私有
4.禁止在容器的循环操作中对容器做增删动作
并发:
1.单例对象的获取需要有多线程安全保护
2.线程创建时最好根据用途赋予线程名称
3.最好使用线程池管理线程,避免手工创建线程
4.高并发的情况下,尽量考虑锁的性能开销,能用无锁的方式最好,实在要使用锁,尽量缩小锁的作用范围
控制:
1.switch的最后必须有一个default处理段
2.避免使用取反逻辑运算符
注释:
1.枚举类型需要为每一个枚举值增加注释说明
2.类,类属性,类方法的注释使用/* 内容 */,而不能用//,以便文档化工具用于自动生成类说明文档
3.不要只注释代码而不写明原因,如果无用的代码就删除,而不是注释掉处理
4.类的注释说明需要有创建者和时间
5.通过TO-DO或者FIX ME注释提醒自己或者其他人当前代码需要进一步处理
异常处理:
1.捕获异常是为了处理异常,如果不处理,要么不捕获,要么将异常抛给上一层调用者处理
2.finally中不要有return(因为多此一举)
日志:
1.日志要有分类(按功能和模块)和等级(error,warn,debug,trace,info)
2.记录异常日志时考虑加入异常调用堆栈输出
单元测试:
1.遵循A(自动化),I(独立性),R(可重复)原则
2.独立性是指测试用例方法间不相互调用,也没有顺序依赖
3.核心模块要保证其单元测试必须通过
4.单元测试的代码需要在模块代码的src同级目录下创建test目录
5.一定要包含如下测试方面(B C D E)
B:边界测试
C:输入的正确性判断测试
D:测试用例的编写需要根据设计文档来进行
E:要有强制将非法数据输入,强制触发非法流程的测试
6.为了方便单元测试,业务代码最好遵循下面的原则
6.1 构造方法尽量简洁
6.2 不要存在大量全局变量和静态方法
6.3 减少外部模块依赖
6.4 避免过多,层次过深的条件判断
架构设计:
1.尽量避免使用继承,而用聚合/组合的方式来实现
2.对于符合里氏代换原则的类,则可以使用继承(例如货币/人民币,美元,日元的关系设计)
3.系统设计阶段的目标是明确需求,确定逻辑以及后期的维护
4.系统设计阶段,就最好梳理出公用的行为做成公共模块,公共配置,公共类,公共方法等
5.开闭原则(对拓展开放,对修改闭合)
6.依赖倒置原则
其他:
1.时刻注意保持DRY原则(Don't repeat yourself)