- 代码总体原则
1.1 Java编程遵循的通用原则：
-
- 清晰第一。易于维护、易于重构。
- 简洁为美。易于理解、易于实现。
- 选择合适的风格，团队保持一致。
1.2 还需要注意一下方面：
面向对象编程隐藏了很多内部实现细节，使用许多JAVA特性时，要注意正确使用。比如：多线程并发、泛型、装箱数据类型、异常处理、对象克隆等。
2. 代码风格
原则1：命名原则:为包、类、方法、变量取一个好名字，使代码易于理解。
原则2：禁止使用魔鬼数字
不要直接使用数字，应采用有意义的静态变量或枚举来代替。
原则3：常量命名，由全大写单词组成，单词间用下划线分隔，且使用 static final修饰
原则4：变量、属性命名，使用名词，并采用首字母小写的驼峰命名法
原则5：方法的命名，用动词和动宾结构，并采用首字母小写的驼峰命名法
建议1： 为保证可读性，方法名不宜过长
建议2 ：类和接口的命名，采用首字母大写的驼峰命名法
建议3 ：包的命名，由一个或若干个单词组成，所有的字母均为小写
建议4 ：数组声明的时候使用 int[] index，而不要使用 int index[]
2.2 注释
原则6：尽量用代码来解释自己
规则1：注释应解释代码的意图，而不是描述代码怎么做的
规则2： 保证注释与代码一致，避免产生误导
规则3 ：注释应与其描述代码位置相邻，放在所注释代码上方或右方，并与代码采用同样缩进
说明:大部分注释应放在代码上方，变量、枚举的注释可选择在代码右方；
建议5 ：在某些场景下，注释语言统一使用英文
建议6 ：不要用注释保留废弃代码
建议7 ：不要用注释记录修改日志
建议8 ：一般单行注释用//，块注释用/* */，JavaDoc注释用/** */
建议9 ：代码简洁明了，尽量让代码行起到自注释作用
2.3 排版
原则7: 团队应遵守一致的排版风格
规则4:将排版风格固化到IDE的代码格式化配置文件中，并让整个团队使用
规则5:在不同的概念之间，增加空行
规则6: 将逻辑紧密相关的代码放在一起
规则7:控制一行的宽度，不要超过120个字符
规则8:将局部变量的作用域最小化
在靠近变量第一次使用处声明变量
建议10: 给if、for、do、while、switch等语句的执行体加大括号{}
建议11: 控制文件的长度，最好不要超过500行
2 变量和类型
原则8: 谨慎使用静态成员变量
要谨记：静态变量是术语类级别的变量。
规则9:避免随意进行类型强制转换，应改善设计，或在转换前用instanceof进行判断
说明：没有判断直接进行类型转换，可能会因类型不匹配而导致运行期异常
对策：在强制转换之前使用instanceof进行判断。
最好的方式还是改善设计，使集合中只有同一种类型的对象。
规则10: 需要精确计算时不要使用float和double
涉及精确的数值计算（货币、金融等），建议使用int, long, BigDecimal等
规则11: 不能用浮点数作为循环变量
规则12: 浮点型数据判断相等不能直接使用==
而应该使用if (Math.abs(a-b) < 1E-6f)
规则13: 避免同一个局部变量在前后表达不同的含义
一个局部变量只应该表达一种含义。
规则14:不要在单个的表达式中对相同的变量赋值超过一次
建议12: 基本类型优于包装类型，注意合理使用包装类型
基本类型优于包装类型，注意合理使用包装类型
使用包装类型合理的场景有：
1、作为集合中的元素、键和值
2、泛型，必须使用包装类型，如List<Integer>
3、进行反射的方法调用时
3 方法
原则9: 方法设计的第一原则是要短小
方法设计的第一原则，是短小，第二原则是还要短小。过长的方法，难以理解和维护。短方法易理解、易维护、易扩展、易测试。根据业界经验，方法的长度建议不超过50行。
原则10: 方法设计应遵循单一职责原则（SRP），一个方法仅完成一个功能
违反单一职责：1、多段代码重复做同一件事情，那么在方法的划分上可能存在问题，应将重复部分提取为一个方法。2、一个方法完成了多种功能，应将其拆分为多个步骤的子功能。
原则11: 方法设计应遵循单一抽象层次原则（SLAP）
原则12: 方法设计应遵循命令与查询职责分离原则（CQRS）
规则15: 不要把方法的入参当做工作变量/临时变量，除非特别需要
规则16: 使用类名调用静态方法，而不要使用实例或表达式来调用
规则17 应明确规定对接口方法参数的合法性检查由调用者负责还是由接口方法本身负责
规则18: 方法的参数个数不宜过多
说明：如果参数超过7个，则维护的难度很大，建议减少参数个数。
如果多个参数同时多次出现在多个方法中，说明这些参数紧密相关，可以将它们封装到一个类中。
规则19: 谨慎使用可变数量参数的方法
4 包、类和接口