命名规范

开发中中容易忽视的是命名规范，下面罗列出项目开发需要注意的命名规范：(其他规范参考下面的编码规范)

常见的命名方法

1.匈牙利命名法：该命名法是在每个变量名的前面加上若干表示数据类型的字符。基本原则是：变量名=属性+类型+对象描述。如i表示int,所有i开头的变量命都表示int类型。s表示String,所有变量命以s开头的都表示String类型变量。

2.骆驼命名法：正如它的名称所表示的那样，是指混合使用大小写字母来构成变量和函数的名字。驼峰命名法跟帕斯卡命名法相似，只是首字母为小写，如userName。因为看上去像驼峰，因此而得名。

3.帕斯卡命名法： 即pascal命名法。做法是首字母大写，如UserName,常用在类的变量命名中。

4.下划线命名法：下划线法是随着C语言的出现流行起来的，在UNIX/LIUNX这样的环境，以及GNU代码中使用非常普遍。

（1）项目和包名命名规范

对于项目和包名命名规范是

1.包名一律小写, 少用缩写和长名；
2.采用以下规则：

• [基本包].[项目名].[模块名]
• 包名一般不要超过三级，级别多了费脑子
• 不得将类直接定义在基本包下，所有项目中的类、接口等都应当定义在各自的项目和模块包中；

例如：

package com.lcw.test.util;
　　这样子的规范，能够提高项目组织性，从而便于更好的协同开发。

Android项目结构命名：

包名

此包中包含

com.xx.应用名称缩写.activity

页面用到的Activity类 (activitie层级名用户界面层)

com.xx.应用名称缩写.base

基础共享的类

com.xx.应用名称缩写.adapter

页面用到的Adapter类 (适配器的类)

com.xx.应用名称缩写.util

此包中包含：公共工具方法类（util模块名）

com.xx.应用名称缩写.bean

下面可分：vo、po、dto 此包中包含：JavaBean类

com.xx.应用名称缩写.model

此包中包含：模型类

com.xx.应用名称缩写.db

数据库操作类

com.xx.应用名称缩写.view (或者 com.xx.应用名称缩写.widget )

自定义的View类等

com.xx.应用名称缩写.service

Service服务

com.xx.应用名称缩写.receiver

BroadcastReceiver服务

注意：
如果项目采用MVP，所有M、V、P抽取出来的接口都放置在相应模块的i包下，所有的实现都放置在相应模块的impl下

（2）类和接口的命名
1.类或接口名是个一名词，采用大小写混合的方式，每个单词的首字母大写。
2.尽量使你的类名简洁而富于描述。
3.使用完整单词，避免用缩写词(除非该缩写词被更广泛使用，像URL，HTML)。

例如：

class Raster;
class ImageSprite;
interface RasterDelegate;
interface Storing;

命名采用单词组合取名，单词首字母为大写，单词之间可采用“_”下划线进行区分，也可不采用。

根据定义类型首字母加以区分：

• Interface：命名首字母加大写的“I”;
• Abstract class：命名首字母加大写“A”;
• Class：无需加

根据功能类型结尾加上功能描述字符串：

• Activity：(LoginActivity,MainActivity…)
• Fragment: TabFragment,MainFragment…
• 处理类：“Handle”，例如“LogicHandle”
• 工厂实现类：“Impl”，例如“FactoryImpl”
• 动作事件定义类：“Action”，例如“LoginAction”
• 网络事件定义类：“Net”，例如“LoginNet”
• 数据定义类：“Data”，例如“LoginData”
• 消息处理类：“Msg”，例如“LoginRequestMsg”
• 资源管理类：“Manager”，例如“ImageManager”
• 缓存类：“Cache”，例如“UserCache”
• 参数传递类：“Param”，例如“LoginParam”
• 功能提供类：“Util”，例如“MathUtil”
• 数据输入输出类：“Steam”，例如“CacheOutStream”

注意事项：

1.类命名不能使用中文字符，不能在命名字符串中出现“0-9”的数值描述和除下划线以外的其他字符描述，命名的字母组合尽量能够在本身的文字意义上初步了解类的大体功能。
2.好的类的命名是，不见注释见名知意。
3.采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写

Android项目命名：

类

描述

例如

Activity

类 Activity为后缀标识

欢迎页面类WelcomeActivity

Adapter类

Adapter 为后缀标识

新闻详情适配器 NewDetailAdapter

解析类

Parser为后缀标识

首页解析类HomePosterParser

工具方法类

Util或Manager为后缀标识（与系统或第三方的Utils区分）或功能+Util 线程池管理类：ThreadPoolManager

日志工具类：LogUtil（Logger也可）打印工具类：PrinterUtil

数据库类

以DBHelper后缀标识

新闻数据库：NewDBHelper

Service类

以Service为后缀标识

时间服务TimeServiceBroadcast

Receiver类

以Receiver为后缀标识

推送接收JPushReceiver

ContentProvider

以Provider为后缀标识

自定义的共享基础类

以Base开头

BaseActivity,BaseFragment

测试类的命名以它要测试的类的名称开始，以Test结束。
例如：HashTest 或 HashIntegrationTest。
接口（interface）：命名规则与类一样采用大驼峰命名法，多以able或ible结尾，如
interface Runnable ;
interface Accessible。

（3）变量命名方法

1.变量名不应以下划线或美元符号开头；
2.尽量避免单个字符的变量名，除非是一次性的临时变量。临时变量通常被取名为i，j，k，m和n，它们一般用于整型；c，d，e，它们一般用于字符型；
3.不建议采用匈牙利命名法则，对不易清楚识别出该变量类型的变量应使用类型名或类型名缩写作其后缀
4.组件或部件变量使用其类型名或类型名缩写作其后缀
5.集合类型变量，例如数组和矢量，应采用复数命名或使用表示该集合的名词做后缀

例如

//首字母小写，两单词以上采用驼峰式命名规范
Thread animationThread;
String responseStr;

Command backCommand;
Image barImage；
TextField passwordField;
Player dogSoundPlayer;

Image[] images;
Vector requestQueue;

（4）常量命名

全部采用大写，单词间用下划线隔开

static final int MIN_WIDTH = 4; 
static final int MAX_WIDTH = 999; 
static final int GET_THE_CPU = 1;

（5）方法命名

1.方法名是一个动词，采用大小写混合的方式，第一个单词的首字母小写，其后单词的首字母大写；
2.取值类可使用get前缀，设值类可使用set前缀，判断类可使用is(has)前缀。
3.对于方法中一定要加上适当的非空判断，与try catch 语句等等程序健壮性的判断

getName();
setSarry();
isLogon();

方法

说明

initXX()

初始化相关方法,使用init为前缀标识，如初始化布局initView()

isXX() checkXX()

方法返回值为boolean型的请使用is或check为前缀标识

getXX()

返回某个值的方法，使用get为前缀标识

handleXX()

对数据进行处理的方法，尽量使用handle为前缀标识

displayXX()/showXX()

弹出提示框和提示信息，使用display/show为前缀标识

saveXX()

与保存数据相关的，使用save为前缀标识

resetXX()

对数据重组的，使用reset前缀标识

clearXX()

清除数据相关的clearMemory()

removeXXX()

清除数据相关的

drawXXX()

绘制数据或效果相关的，使用draw前缀标识

下划线可能出现在JUnit测试方法名称中用以分隔名称的逻辑组件。一个典型的模式是：test_，例如testPop_emptyStack。
并不存在唯一正确的方式来命名测试方法。

(6).资源文件命名规范

1. 资源布局文件（XML文件（layout布局文件））：

   全部小写，采用下划线命名法

1) contentview 命名
必须以全部单词小写，单词间以下划线分割，使用名词或名词词组。
所有Activity或Fragment的contentView必须与其类名对应，对应规则为：
将所有字母都转为小写，将类型和功能调换（也就是后缀变前缀）。

例如：activity_main.xml

2) Dialog命名：dialog_描述.xml

例如：dialog_hint.xml

3) PopupWindow命名：ppw_描述.xml

例如：ppw_info.xml

4) 列表项命名：item_描述.xml

例如：item_city.xml

5) 包含项命名：模块_(位置)描述.xml

例如：activity_main_head.xml、activity_main_bottom.xml
注意：通用的包含项命名采用：项目名称缩写_描述.xml
例如：xxxx_title.xml

2.资源文件（图片drawable文件夹下）：

全部小写，采用下划线命名法，加前缀区分
命名模式：可加后缀 _small 表示小图, _big 表示大图，逻辑名称可由多个单词加下划线组成，采用以下规则：
用途_模块名_逻辑名称
用途_模块名_颜色
用途_逻辑名称
用途_颜色

说明：用途也指控件类型（具体见UI控件缩写表）
例如：

btn_main_home.png 按键
divider_maket_white.png 分割线
ic_edit.png 图标
bg_main.png 背景
btn_red.png 红色按键
btn_red_big.png 红色大按键
ic_head_small.png 小头像
bg_input.png 输入框背景
divider_white.png 白色分割线

如果有多种形态如按钮等除外如 btn_xx.xml（selector）

名称

功能

btn_xx

按钮图片使用btn_整体效果（selector）

btn_xx_normal

按钮图片使用btn_正常情况效果

btn_xx_pressed

按钮图片使用btn_点击时候效果

btn_xx_focused

state_focused聚焦效果

btn_xx_disabled

state_enabled (false)不可用效果

btn_xx_checked

state_checked选中效果

btn_xx_selected

state_selected选中效果

btn_xx_hovered

state_hovered悬停效果

btn_xx_checkable

state_checkable可选效果

btn_xx_activated

state_activated激活的

btn_xx_windowfocused

state_window_focused

bg_head

背景图片使用bg_功能_说明

def_search_cell

默认图片使用def_功能_说明

ic_more_help

图标图片使用ic_功能_说明

seg_list_line

具有分隔特征的图片使用seg_功能_说明

sel_ok

选择图标使用sel_功能_说明

注意：
使用AndroidStudio的插件SelectorChapek可以快速生成selector，前提是命名要规范。
3. 动画文件（anim文件夹下）：
全部小写，采用下划线命名法，加前缀区分。
具体动画采用以下规则：
模块名_逻辑名称
逻辑名称
refresh_progress.xml
market_cart_add.xml
market_cart_remove.xml
普通的tween动画采用如下表格中的命名方式
// 前面为动画的类型，后面为方向

动画命名例子

规范写法

fade_in

淡入

fade_out

淡出

push_down_in

从下方推入

push_down_out

从下方推出

push_left

推向左方

slide_in_from_top

从头部滑动进入

zoom_enter

变形进入

slide_in

滑动进入

shrink_to_middle

中间缩小

4. values中name命名

类别 命名 示例
strings strings的name命名使用下划线命名法，采用以下规则：
模块名+逻辑名称

main_menu_about 主菜单按键文字
friend_title 好友模块标题栏

friend_dialog_del 好友删除提示

login_check_email 登录验证

dialog_title 弹出框标题

button_ok 确认键 loading 加载文字

colors  colors的name命名使用下划线命名法，采用以下规则：
模块名+逻辑名称 颜色

friend_info_bg friend_bg transparent gray
styles  styles的name命名使用 Camel命名法，采用以下规则：模块名+逻辑名称    main_tabBottom

5 .layout中的id命名
命名模式为：view缩写_view的逻辑名称
使用 AndroidStudio 的插件 ButterKnife Zelezny，生成注解非常方便。
如果不使用 ButterKnife Zelezny，则建议使用 view 缩写做后缀，如：

username_tv（展示用户名的TextView）

（7）注释

注释，是程序维护的灵魂。
原则——对已经不推荐使用的类和方法需要注明@Deprecated，并说明替代的类或者方法；
对于针对集合、开关的方法，要在方法注释中表明是否多线程安全。

文件注释
所有的源文件都应该在开头有一个注释，其中列出文件的版权声明、文件名、功能描述以及创建、修改记录

/*
 * Copyright (C) 2009-2014 liucw Inc.All Rights Reserved.
 * FileName：HelloWorld.java
 * @Description：简要描述本文件的内容
 * History：
 * 版本号  作者  日期         简要介绍相关操作
 *  1.0   liucw 2014-03-21  Create
 *  1.1   liucw 2014-03-23  Add Hello World
 */

类或接口注释
采用JavaDoc文档注释，在类、接口定义之前应当对其进行注释，包括类、接口的描述、最新修改者、版本号、参考链接等

/** 
 * 描述
 * @author liucw（最新修改者）
 * @version 1.0 （最新版本号）
 * @see 参考的JavaDoc
 */
class Window extends BaseWindow 
{
   ...
}

JavaDoc文档注释：

1.描述Java的类、接口、构造方法、方法、以及字段。
2.每个文档注释都会被置于注释定界符/*…/之中，一个注释对应一个类、接口或成员。
3.该注释应位于声明之前。
4.文档注释的第一行(/**)不需缩进，随后的文档注释每行都缩进1格(使星号纵向对齐)。

方法注释
采用JavaDoc文档注释，在方法定义之前当对其进行注释，包括方法的描述、输入、输出及返回值说明、抛出异常说明、参考链接等

 /**
  * @author liucw
  * @Description: ${todo}
  * @date ${date} ${time}
  * @param 参数说明：每个参数一行，注明其取值范围等
  * @return 返回值：注释出失败、错误、异常时的返回情况
  * @exception 异常：注释出什么条件下会引发什么样的异常
  * @see 参考的JavaDoc
  */

public char charAt(int index) 
{
       ...
}

其它注释(非JavaDoc文档注释)

1.单行代码注释一律使用注释界定符”//”

// explain what this means
if(bar > 1)
{
    ……
}
int isShow = 0;// 是否显示

2.多行注释使用注释界定符”/…/”

/*
 * Here is a block comment with 
 * multiple lines for text comments.
 */


这些命名规范和注释，看似是微不足道一小步，却是我们通往专业的一大步

编码规范

以下是从规范中摘录的一些内容：
1.import中不能有通配符。
2.重载方法应该放在一起连续出现。
3.即使代码块中没有内容，或者只有一行代码，也必须使用大括号。
4.2空格缩进。
5.列宽是80或100个字符。
6.不能使用类似C语言的数组变量声明。
7.switch语句中，必须包含default语句。
8.修饰符的顺序应按照Java语言规范推荐的顺序。
9.常量命名应使用CONSTANT_CASE格式（译注：所有字母大写，单词使用下划线分隔）。注意，所有常量都必须是static final成员，但并不是所有的static final成员都是常量。
10.其他命名规范分别采用驼峰式命名规则(CamelCase)例如：首字母为小写，如userName。因为看上去像驼峰

参考google Java编程风格规范：http://hawstein.com/posts/google-java-style.html

源文件基础

1.1 文件名
源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。

1.2 文件编码：UTF-8
源文件编码格式为UTF-8。必须统一编码格式

1.3 特殊字符

1.3.1 空白字符
除了行结束符序列，ASCII水平空格字符(0x20，即空格)是源文件中唯一允许出现的空白字符，这意味着：

• 所有其它字符串中的空白字符都要进行转义。
• 制表符不用于缩进。

1.3.2 特殊转义序列
对于具有特殊转义序列的任何字符(\b, \t, \n, \f, \r, \“, \‘及)，我们使用它的转义序列，而不是相应的八进制(比如\012)或Unicode(比如\u000a)转义。

1.3.3 非ASCII字符
对于剩余的非ASCII字符，是使用实际的Unicode字符(比如∞)，还是使用等价的Unicode转义符(比如\u221e)，取决于哪个能让代码更易于阅读和理解。

Tip: 在使用Unicode转义符或是一些实际的Unicode字符时，建议做些注释给出解释，这有助于别人阅读和理解。

例如：

String unitAbbrev = "μs";                                 | 赞，即使没有注释也非常清晰
String unitAbbrev = "\u03bcs"; // "μs"                    | 允许，但没有理由要这样做
String unitAbbrev = "\u03bcs"; // Greek letter mu, "s"    | 允许，但这样做显得笨拙还容易出错
String unitAbbrev = "\u03bcs";                            | 很糟，读者根本看不出这是什么
return '\ufeff' + content; // byte order mark             | Good，对于非打印字符，使用转义，并在必要时写上注释

Tip: 永远不要由于害怕某些程序可能无法正确处理非ASCII字符而让你的代码可读性变差。当程序无法正确处理非ASCII字符时，它自然无法正确运行， 你就会去fix这些问题的了。(言下之意就是大胆去用非ASCII字符，如果真的有需要的话)

源文件结构

一个源文件包含(按顺序地)：

1.许可证或版权信息(如有需要)
2.package语句
3.import语句
4.一个顶级类(只有一个)
以上每个部分之间用一个空行隔开。

2.1 许可证或版权信息
如果一个文件包含许可证或版权信息，那么它应当被放在文件最前面。

2.2 package语句
package语句不换行，列限制(4.4节)并不适用于package语句。(即package语句写在一行里)

2.3 import语句
2.3.1 import不要使用通配符
即，不要出现类似这样的import语句：import java.util.*;

2.3.2 不要换行
import语句不换行，列限制(4.4节)并不适用于import语句。(每个import语句独立成行)

2.3.3 顺序和间距
import语句可分为以下几组，按照这个顺序，每组由一个空行分隔：

1.所有的静态导入独立成组
2.com.google imports(仅当这个源文件是在com.google包下)
3.第三方的包。每个顶级包为一组，字典序。例如：android, com, junit, org, sun
4.java imports
5.javax imports
组内不空行，按字典序排列。

2.4 类声明
2.4.1 只有一个顶级类声明
每个顶级类都在一个与它同名的源文件中(当然，还包含.java后缀)。

例外：package-info.java，该文件中可没有package-info类。

2.4.2 类成员顺序
类的成员顺序对易学性有很大的影响，但这也不存在唯一的通用法则。不同的类对成员的排序可能是不同的。 最重要的一点，每个类应该以某种逻辑去排序它的成员，维护者应该要能解释这种排序逻辑。比如， 新的方法不能总是习惯性地添加到类的结尾，因为这样就是按时间顺序而非某种逻辑来排序的。

2.4.2.1 重载：永不分离
当一个类有多个构造函数，或是多个同名方法，这些函数/方法应该按顺序出现在一起，中间不要放进其它函数/方法。

格式

术语说明：块状结构(block-like construct)指的是一个类，方法或构造函数的主体。需要注意的是，数组初始化中的初始值可被选择性地视为块状结构(3.8.3.1节)。

3.1 大括号
3.1.1 使用大括号(即使是可选的)
大括号与if, else, for, do, while语句一起使用，即使只有一条语句(或是空)，也应该把大括号写上。

3.1.2 非空块：K & R 风格
对于非空块和块状结构，大括号遵循Kernighan和Ritchie风格 (Egyptian brackets):

• 左大括号前不换行

• 左大括号后换行

• 右大括号前换行

• 如果右大括号是一个语句、函数体或类的终止，则右大括号后换行; 否则不换行。例如，如果右大括号后面是else或逗号，则不换行。
  示例：

  //采用IDE的code review会自动格式化你编写的代码
  return new MyClass() {
  @Override public void method() {
  if (condition()) {
  try {
  something();
  } catch (ProblemException e) {
  recover();
  }
  }
  }
  };

3.1.3 空块：可以用简洁版本
一个空的块状结构里什么也不包含，大括号可以简洁地写成{}，不需要换行。例外：如果它是一个多块语句的一部分(if/else 或 try/catch/finally) ，即使大括号内没内容，右大括号也要换行。

示例：

void doNothing() {}

3.2 块缩进：2个空格
每当开始一个新的块，缩进增加2个空格，当块结束时，缩进返回先前的缩进级别。缩进级别适用于代码和注释。(见4.1.2节中的代码示例)

3.3 一行一个语句
每个语句后要换行。

3.4 列限制：80或100
一个项目可以选择一行80个字符或100个字符的列限制，除了下述例外，任何一行如果超过这个字符数限制，必须自动换行。

例外：

不可能满足列限制的行(例如，Javadoc中的一个长URL，或是一个长的JSNI方法参考)。
package和import语句(见2.2节和2.3节)。
注释中那些可能被剪切并粘贴到shell中的命令行。

3.5 自动换行
术语说明：一般情况下，一行长代码为了避免超出列限制(80或100个字符)而被分为多行，我们称之为自动换行(line-wrapping)。

我们并没有全面，确定性的准则来决定在每一种情况下如何自动换行。很多时候，对于同一段代码会有好几种有效的自动换行方式。

Tip: 提取方法或局部变量可以在不换行的情况下解决代码过长的问题(是合理缩短命名长度吧)

3.5.1 从哪里断开
自动换行的基本准则是：更倾向于在更高的语法级别处断开。

1.如果在非赋值运算符处断开，那么在该符号前断开(比如+，它将位于下一行)。注意：这一点与Google其它语言的编程风格不同(如C++和JavaScript)。 这条规则也适用于以下“类运算符”符号：点分隔符(.)，类型界限中的&（

Note：这个规则并不要求或禁止一行的开关或结尾需要额外的空格，只对内部空格做要求。

3.6.3 水平对齐：不做要求
术语说明：水平对齐指的是通过增加可变数量的空格来使某一行的字符与上一行的相应字符对齐。

这是允许的(而且在不少地方可以看到这样的代码)，但Google编程风格对此不做要求。即使对于已经使用水平对齐的代码，我们也不需要去保持这种风格。

以下示例先展示未对齐的代码，然后是对齐的代码：

private int x; // this is fine
private Color color; // this too

private int   x;      // permitted, but future edits
private Color color;  // may leave it unaligned

Tip：对齐可增加代码可读性，但它为日后的维护带来问题。考虑未来某个时候，我们需要修改一堆对齐的代码中的一行。 这可能导致原本很漂亮的对齐代码变得错位。很可能它会提示你调整周围代码的空白来使这一堆代码重新水平对齐(比如程序员想保持这种水平对齐的风格)， 这就会让你做许多的无用功，增加了reviewer的工作并且可能导致更多的合并冲突。

3.7 用小括号来限定组：推荐
除非作者和reviewer都认为去掉小括号也不会使代码被误解，或是去掉小括号能让代码更易于阅读，否则我们不应该去掉小括号。 我们没有理由假设读者能记住整个Java运算符优先级表。

3.8 具体结构
3.8.1 枚举类
枚举常量间用逗号隔开，换行可选。

没有方法和文档的枚举类可写成数组初始化的格式：

private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }
由于枚举类也是一个类，因此所有适用于其它类的格式规则也适用于枚举类。

3.8.2 变量声明
3.8.2.1 每次只声明一个变量
不要使用组合声明，比如int a, b;。

3.8.2.2 需要时才声明，并尽快进行初始化
不要在一个代码块的开头把局部变量一次性都声明了(这是c语言的做法)，而是在第一次需要使用它时才声明。 局部变量在声明时最好就进行初始化，或者声明后尽快进行初始化。

3.8.3 数组
3.8.3.1 数组初始化：可写成块状结构
数组初始化可以写成块状结构，比如，下面的写法都是OK的：

new int[] {
  0, 1, 2, 3 
}

new int[] {
  0,
  1,
  2,
  3
}

new int[] {
  0, 1,
  2, 3
}

new int[]
    {0, 1, 2, 3}

3.8.3.2 非C风格的数组声明

中括号是类型的一部分：String[] args， 而非String args[]。

3.8.4 switch语句
术语说明：switch块的大括号内是一个或多个语句组。每个语句组包含一个或多个switch标签(case FOO:或default:)，后面跟着一条或多条语句。

3.8.4.1 缩进
与其它块状结构一致，switch块中的内容缩进为2个空格。

每个switch标签后新起一行，再缩进2个空格，写下一条或多条语句。

3.8.4.2 Fall-through：注释
在一个switch块内，每个语句组要么通过break, continue, return或抛出异常来终止，要么通过一条注释来说明程序将继续执行到下一个语句组， 任何能表达这个意思的注释都是OK的(典型的是用// fall through)。这个特殊的注释并不需要在最后一个语句组(一般是default)中出现。示例：

switch (input) {
  case 1:
  case 2:
    prepareOneOrTwo();
    // fall through
  case 3:
    handleOneTwoOrThree();
    break;
  default:
    handleLargeNumber(input);
}

3.8.4.3 default的情况要写出来
每个switch语句都包含一个default语句组，即使它什么代码也不包含。

3.8.5 注解(Annotations)
注解紧跟在文档块后面，应用于类、方法和构造函数，一个注解独占一行。这些换行不属于自动换行(第4.5节，自动换行)，因此缩进级别不变。例如：

@Override
@Nullable
public String getNameIfPresent() { ... }
例外：单个的注解可以和签名的第一行出现在同一行。例如：

@Override public int hashCode() { ... }
应用于字段的注解紧随文档块出现，应用于字段的多个注解允许与字段出现在同一行。例如：

@Partial @Mock DataLoader loader;
参数和局部变量注解没有特定规则。

3.8.6 注释
3.8.6.1 块注释风格
块注释与其周围的代码在同一缩进级别。它们可以是/* … /风格，也可以是// …风格。对于多行的/ … /注释，后续行必须从开始， 并且与前一行的*对齐。以下示例注释都是OK的。

/*
 * This is          // And so           /* Or you can
 * okay.            // is this.          * even do this. */
 */
注释不要封闭在由星号或其它字符绘制的框架里。

Tip：在写多行注释时，如果你希望在必要时能重新换行(即注释像段落风格一样)，那么使用/* ... */。

3.8.7 Modifiers
类和成员的modifiers如果存在，则按Java语言规范中推荐的顺序出现。

public protected private abstract static final transient volatile synchronized native strictfp

命名约定

4.1 对所有标识符都通用的规则
标识符只能使用ASCII字母和数字，因此每个有效的标识符名称都能匹配正则表达式\w+。

在Google其它编程语言风格中使用的特殊前缀或后缀，如name_, mName, s_name和kName，在Java编程风格中都不再使用。

4.2 标识符类型的规则
4.2.1 包名
包名全部小写，连续的单词只是简单地连接起来，不使用下划线。

4.2.2 类名
类名都以UpperCamelCase风格编写。

类名通常是名词或名词短语，接口名称有时可能是形容词或形容词短语。现在还没有特定的规则或行之有效的约定来命名注解类型。

测试类的命名以它要测试的类的名称开始，以Test结束。例如，HashTest或HashIntegrationTest。

4.2.3 方法名
方法名都以lowerCamelCase风格编写。

方法名通常是动词或动词短语。

下划线可能出现在JUnit测试方法名称中用以分隔名称的逻辑组件。一个典型的模式是：test_，例如testPop_emptyStack。 并不存在唯一正确的方式来命名测试方法。

4.2.4 常量名
常量名命名模式为CONSTANT_CASE，全部字母大写，用下划线分隔单词。那，到底什么算是一个常量？

每个常量都是一个静态final字段，但不是所有静态final字段都是常量。在决定一个字段是否是一个常量时， 考虑它是否真的感觉像是一个常量。例如，如果任何一个该实例的观测状态是可变的，则它几乎肯定不会是一个常量。 只是永远不打算改变对象一般是不够的，它要真的一直不变才能将它示为常量。

// Constants
static final int NUMBER = 5;
static final ImmutableList<String> NAMES = ImmutableList.of("Ed", "Ann");
static final Joiner COMMA_JOINER = Joiner.on(',');  // because Joiner is immutable
static final SomeMutableType[] EMPTY_ARRAY = {};
enum SomeEnum { ENUM_CONSTANT }

// Not constants
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final Set<String> mutableCollection = new HashSet<String>();
static final ImmutableSet<SomeMutableType> mutableElements = ImmutableSet.of(mutable);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};

这些名字通常是名词或名词短语。

4.2.5 非常量字段名
非常量字段名以lowerCamelCase风格编写。

这些名字通常是名词或名词短语。

4.2.6 参数名
参数名以lowerCamelCase风格编写。

参数应该避免用单个字符命名。

4.2.7 局部变量名
局部变量名以lowerCamelCase风格编写，比起其它类型的名称，局部变量名可以有更为宽松的缩写。

虽然缩写更宽松，但还是要避免用单字符进行命名，除了临时变量和循环变量。

即使局部变量是final和不可改变的，也不应该把它示为常量，自然也不能用常量的规则去命名它。

4.2.8 类型变量名
类型变量可用以下两种风格之一进行命名：

• 单个的大写字母，后面可以跟一个数字(如：E, T, X, T2)。
• 以类命名方式(4.2.2节)，后面加个大写的T(如：RequestT, FooBarT)。

4.3 驼峰式命名法(CamelCase)

驼峰式命名法分大驼峰式命名法(UpperCamelCase)和小驼峰式命名法(lowerCamelCase)。 有时，我们有不只一种合理的方式将一个英语词组转换成驼峰形式，如缩略语或不寻常的结构(例如”IPv6”或”iOS”)。Google指定了以下的转换方案。

名字从散文形式(prose form)开始:

1.把短语转换为纯ASCII码，并且移除任何单引号。
例如：”Müller’s algorithm”将变成”Muellers algorithm”。

2.把这个结果切分成单词，在空格或其它标点符号(通常是连字符)处分割开。

• 推荐：如果某个单词已经有了常用的驼峰表示形式，按它的组成将它分割开(如”AdWords”将分割成”ad words”)。 需要注意的是”iOS”并不是一个真正的驼峰表示形式，因此该推荐对它并不适用。

3.现在将所有字母都小写(包括缩写)，然后将单词的第一个字母大写：最后将所有的单词连接起来得到一个标识符。

• 每个单词的第一个字母都大写，来得到大驼峰式命名。

• 除了第一个单词，每个单词的第一个字母都大写，来得到小驼峰式命名。
  示例：

  Prose form Correct Incorrect

  "XML HTTP request" XmlHttpRequest XMLHTTPRequest
  "new customer ID" newCustomerId newCustomerID
  "inner stopwatch" innerStopwatch innerStopWatch
  "supports IPv6 on iOS?" supportsIpv6OnIos supportsIPv6OnIOS
  "YouTube importer" YouTubeImporter
  YoutubeImporter*

加星号处表示可以，但不推荐。

Note：在英语中，某些带有连字符的单词形式不唯一。例如："nonempty"和"non-empty"都是正确的，因此方法名checkNonempty和checkNonEmpty也都是正确的。

其他

1. 列表内容
2.使用 Gradle 和它推荐的工程结构
3.把密码和敏感数据放在gradle.properties
4.不要自己写 HTTP 客户端,使用Volley或OkHttp库
5.使用Jackson库解析JSON数据
6.避免使用Guava同时使用一些类库来避免65k 
7.使用 Fragments来呈现UI视图
8.使用 Activities 只是为了管理 Fragments
9.Layout 布局是 XMLs代码，组织好它们
10.在layoutout XMLs布局时，使用styles文件来避免使用重复的属性
11.使用多个style文件来避免单一的一个大style文件
12.保持你的colors.xml 简短DRY(不要重复自己)，只是定义调色板
13.总是使用dimens.xml DRY(不要重复自己)，定义通用常数
14.不要做一个深层次的ViewGroup
15.在使用WebViews时避免在客户端做处理，当心内存泄露
16.使用Robolectric单元测试，Robotium 做UI测试
17.使用Genymotion 作为你的模拟器
18.总是使用ProGuard 和 DexGuard混淆来项目

参考：
1.Google Java编程风格指南

2.Android团队开发规范

3.Android 编码规范

4.[干货] Android 开发规范与应用