前言

这第三章主要是讲一些代码风格和规范，代码风格不影响程序运行，但对于团队的合作开发效率十分重要，相对前两章，这章内容较少

命名规约

• 命名符合本语言特性 每种语言都有自己的特殊风格，比如java不能以下划线，$开始结束
• 命名体现代码元素特征 比如
  首字母大写的大驼峰，或者首字母小写的小驼峰；
  类名一般采取大驼峰，
  方法名采取小驼峰，
  包括参数，成员变量，局部变量采用小驼峰，
  常量字母全部大写，单词之间用下划线连接；
  包名统一小写，一个包用一个自然单词
  抽象类名使用Abstract或者Base开头，异常类名用Exception结尾，测试类名用它要测试的类名开始，Test结尾
  定义数组类型与中括号相连
  枚举类名用Enum作为后缀，成员名称全部大写，单词间下划线分割
• 命名做到望文知义 这样命名需要反复推敲，但之后上下文理解时会方便，一般是以英文作为标准，这样方便国际化，拼音和首字母命名就会难以理解或者误解

常量

常量就是不变的值，用final修饰，分全局，类内，局部
-全局常量即为类的公开静态属性，用public static final修饰
-类内是私有静态属性，使用private staic final修饰
-局部分为方法常量和参数常量，
方法常量：方法及代码块内定义的常量；参数常量：定义形参时，增加final修饰，代表不可修改
-全局和类内常量使用字母与全部大写，单词间下划线，局部常量使用小驼峰

• 魔法值，魔法值就是指一些不确定的对应数字，比如这段代码
• 
  2和3分别代表未审核和线下课程，团队规模小时还能记住，但团队一大，别人不知道这些数字的含义，搞混了以后就会造成错误，之后重构代码，用枚举类改进这个功能
  
  也可以用不可实例化的抽象类进行课程状态的表示，如下
  
  
  如下可以看到代码可读性很好了
  
  这里说重构是不可避免的，但良好的设计可以让重构来的晚一些，幅度小一些
  甚至一些true和false也可以定义为类内常量，如红黑树的源码
  

变量

变量包括成员变量和局部可变变量
一般满足小驼峰格式，体现出业务含义即可，有一些值得注意的点：在POJO类中，布尔类型的变量命名不要加is前缀，否则部分框架会解析出现序列化错误，比如是否删除定义为isDeleted，那么getter方法时isDeleted,框架会误以为属性名是deleted，就获取不到属性了