1.直白式的代码比起注释来的更有意义
2.空格、换行相关的规范，编辑完代码后执行格式化操作
3.Coders不能为了图方便而牺牲了代码的健壮性和可理解性
1 命名
1.1 命名需要富有含义，尽量能达到见名知义的程度，避免无意义的命名。
1.2 变量名详细程度，根据变量作用范围而定，成员变量 > 大函数的局部变量 > 小函数的局部变量，作用域越大，变量名则应更详细。
如对于一个类型的变量，成员变量命名为mCachedShareConfigEvent ，小函数的局部变量可以命名为event。
1.3 类名
采用大驼峰命名法，尽量避免缩写。Activity 、Fragment、Adapter等常见类型应添加对应的后缀标识。
类名通常是名词或名词短语，接口名称有时可能是形容词或形容词短语。
1.4 方法名
- 采用小驼峰命名法，方法名通常是动词或动词短语。布尔类型函数使用谓语动词为前缀。
如initXX()、displayXX()、isXX()。
- 回调类方法，添加On前缀，如onRequestFaild(MobileErrorCode mobileErrorCode)
1.5 变量名
- 采用小驼峰命名法，成员变量以m开头。常量名命名模式为CONSTANT_CASE，静态变量s开头
- 前缀后面，是由表意性强的一个单词或多个单词组成的名字。
- 最后，可以根据情况添加类型、量词后缀。
ps：因为xml中控件的命名限制，及框架的View注入原因。控件类变量名为单词小写，单词间以下划线分割，以控制类型缩写为前缀（控件缩写表见文档末尾）。
例：mFollowingAnchorInfos，lv_following_anchors。
1.6 资源文件命名：因为资源类型需要在代码中以R文件引用，所以总体规则为：类型前缀+逻辑描述，方便查找。
类型 举例 说明
contentView fragment_room
fragment_anchor_card_detail Fragment的contentView必须与其类名对应，
将所有字母都转为小写，将类型和功能调换（也就是后缀变前缀）
列表项 item_following_anchors.xml item_描述.xml
id命名 lv_following_anchors
btn_rotate_screen view缩写_view的_=BB辑名称
2 注释
2.1 每个public类，及它的每个public成员变量、方法尽量添加注释，需说明参数，返回值。
例外：不言自明的方法，如getter、setter方法。重载的方法。
2.2 其他需要添加注释的地方
重要的private函数、变量；难于理解地方；特殊的业务逻辑、约定；
ps：注释主要是为了说明变量名、方法名无法阐述的含义，不要直接翻译。如果命名足够好，可以不写注释。
3 代码数量限制
3.1 一个函数体不要超过80行
3.2 函数中大括号不要超过4层
3.3 三行以上（包括三行）重复三次（包括三次）以上，或五行以上（包括五行）重复两次（包括两次）以上，代码必须另写出一个函数；如果有一两个地方不同，要考虑使用参数进行概括，而使之成为共用的一段代码
4 其他
4.1 避免魔数，如if(res.result == 99)
4.2 xml布局，对于整体布局-子View有间距需求的，统一父布局做统一的上下左右间隔，不要在每个子控件去做整体布局的上下左右间距处理。
4.3 所有用到LayoutParams类的地方，都需伴随其外部类使用，避免因为自动导包，导入了非预期LayoutParams类。如 new AbsListView.LayoutParams 。
4.4 动态数组，如果不能确定数组情况，一定要进行越界检查，避免考虑不周导致数组越界。
-不好的变量名举例
private ClickDiminishListView cdlList; 无意义
private ArrayList<RewardBasicItem> reList; 无意义