代码格式，注意事项

命名规则

• 包名必须以com开头，后面跟有项目名称（或者缩写）,再后面为模块名或层级名称;

• 类名，接口名，方法名，变量名，必须使用驼峰规则，尽量选用通用词汇；

• 常量的命名，应该全部大写，单词间用下划线隔开。

• layout xml 的命名必须以 全部单词小写，单词间以下划线分割：

  Activity 的 layout 以 activity 开头
  Fragment 的 layout 以 fragment 开头
  Dialog 的 layout 以 dialog 开头
  include 的 layout 以 include 开头
  ListView 的行 layout 以 list_item 开头
  RecyclerView 的 item layout 以 recycle_item 开头
  GridView 的行 layout 以 grid_item 开头
  如果是在特定项目中，需要在前面加上module的标示。如alibaba_activity。

• id的命名，小写+下划线。结尾以控件缩写。如：title_tv,poster_iv。

• 资源的命名，同样是单词小写+下划线。
  所有的命名注意避免拼写错误。

注释规范

• 类注释：
  模板设置:Android Studio -> File -> Settings -> 左上角搜索 File and Code Templates -> 右边面板选择Class

/**
 * Author ${USER} 
 * Date ${DATE}
 * Desc 
 */

desc加上这个类的简短描述，让人一目了然。

• 方法注释
  不要求所有方法都添加注释,但容易产生歧义或功能不清的方法需添加文档注释。
  需要对参数和返回值进行说明的，需要使用:

/**
     * 
     * @param keyCode
     * @param event
     * @return
     */

• 类成员变量和常量注释
  类成员变量和常量, 通常情况注释写在声明的上方。

• 其他注释
  方法内部的注释多行 使用/*…… */形式，如果为单行是用//……形式的注释；部分自定义的枚举，数字标识一定要加上注释；另外接口中的方法必须加上文档注释。

规约

• 方法
  一个方法尽量不要超过15行，如果方法太长，说明当前方法业务逻辑已经非常复杂，那么就需要进行方法拆分，保证每个方法只作一件事。
  不要使用 try catch 处理业务逻辑。
• 参数和返回值
  一个方法的参数尽可能的不要超过4个！
  如果一个方法返回的是一个错误码，请使用异常！！
  尽可能不要使用null， 替代为异常 或者使用空变量 如返回 List 则可以使用Collections.emptyList()
• 神秘的数
  代码中不允许出现单独的数字，字符！如果需要使用数字或字符，则将它们按照含义封装为静态常量！（for语句中除外）
  -- 控制语句
  判断中如有常量，则应将常量置于判断式的右侧。如：

if ( true == isAdmin()){
    //...
}

if中多条件的情况，抽出来用变量定义，不要把多个判断全部放在if中
多个if else的情况，最后的else要加上，避免单边。

• 异常的捕捉处理
  通常的思想是只对错误采用异常处理：逻辑和编程错误，设置错误，被破坏的数据，资源耗尽，等等。
  通常的法则是系统在正常状态下以及无重载和硬件失效状态下，不应产生任何异常。
  最小化从一个给定的抽象类中导出的异常的个数。对于经常发生的可预计事件不要采用异常。不要使用异常实现控制结构。
  若有finally 子句，则不要在try 块中直接返回，亦不要在finally 中直接返回。

• 访问控制
  若没有足够理由，不要把实例或类变量声明为公有。通常，实例变量无需显式的设置(set)和获取(gotten)，通常这作为方法调用的边缘效应 (side effect)而产生。
  一个具有公有实例变量的恰当例子，是类仅作为数据结构，没有行为。亦即，若你要使用一个结构(struct)而非一个类(如果java 支持结构的话)，那么把类的实例变量声明为公有是合适的。

• 资源引用
  layout和code中不要使用hard code资源值，资源值定义在dimens，colors和integers等资源文件中，被外部引用。
  控件尽量使用style来定义组合样式，利用style的继承关系，复用资源。

• 内部类的使用(避免内存泄漏)
  可以用内部类， 不过用的时候，内部类需要是静态的，如果用到外层类的context，需要使用弱引用。
  如果内部类跟外部类生命周期是同步的，则不需要考虑内存泄漏问题。所以主要是异步的内部类或者匿名内部类造成内存泄漏。
  如果可以，尽量少用内部类的形式

• TODO只是临时使用的提示方式，加上相应的代码后及时删除

• 代码中警告的部分，尽量避免。如出现黄色警告部分，无论是注释中的，还是代码中，都尽量去除，增强代码健壮性。