这份文档参考了Google Java Style Guide和官方Android Code Style for Contributors 编码风格规范。该文档仅供参考。基本格式方面使用 AndroidStudio 默认模板即可（使用格式化快捷键(ctrl+alt+L/commond+alt+L)、Eclipes(ctrl+shift+F)处理后基本符合）。
源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。
源文件编码格式为UTF-8。
对于具有特殊转义序列的任何字符(\b, \t, \n, \f, \r, \”, \’及)，我们使用它的转义序列，而不是相应的八进制(比如\012)或Unicode(比如\u000a)转义。
对于剩余的非ASCII字符，是使用实际的Unicode字符(比如∞)，还是使用等价的Unicode转义符(比如\u221e)，取决于哪个能让代码更易于阅读和理解。
Tip:在使用Unicode转义符或是一些实际的Unicode字符时，建议做些注释给出解释，这有助于别人阅读和理解。 例如：
//最好的，即使没有注释也非常清晰
String unitAbbrev = "μs";
//允许，但没有理由要这样做
String unitAbbrev = "\u03bcs"; // "μs"
//允许，但这样做显得笨拙还容易出错
String unitAbbrev = "\u03bcs"; // Greek letter mu, "s"
//很糟，读者根本看不出这是什么
String unitAbbrev = "\u03bcs";
//Good，对于非打印字符，使用转义，并在必要时写上注释
return '\ufeff' + content; // byte order mark | Example | Discussion |
|---|---|
| String unitAbbrev = "μs"; | Best: perfectly clear even without a comment. |
| String unitAbbrev = "\u03bcs"; // "μs" | Allowed, but there's no reason to do this. |
| String unitAbbrev = "\u03bcs"; // Greek letter mu, "s" | Allowed, but awkward and prone to mistakes. |
| String unitAbbrev = "\u03bcs"; | Poor: the reader has no idea what this is. |
| return '\ufeff' + content; // byte order mark | Good: use escapes for non-printable characters, and comment if necessary. |
Tip:永远不要由于害怕某些程序可能无法正确处理非ASCII字符而让你的代码可读性变差。当程序无法正确处理非ASCII字符时，它自然无法正确运行， 你就会去fix这些问题的了。
1.许可证或版权信息(如有需要) 2.package语句 3.import语句 4.主内容
Tip:每个部分之间用一个空行隔开。
如果一个文件包含许可证或版权信息，那么它应当被放在文件最前面。
package 语句不换行，列限制(4.4节)并不适用于package语句。(即package语句写在一行里)
即，不要出现类似这样的import语句：import java.util.*;
import语句不换行，列限制并不适用于import语句。
import语句可分为以下几组，按照这个顺序，每组由一个空行分隔：
所有的静态导入独立成组 com.google imports(仅当这个源文件是在com.google包下) 第三方的包。每个顶级包为一组，字典序。例如：android, com, junit, org, sun java imports5.javax imports组内不空行，按字典序排列。
注：Android Studio会自动帮我们完成
类声明每个顶级类都在一个与它同名的源文件中(当然，还包含.java后缀)。 例外：package-info.java，该文件中可没有package-info类。
类的成员顺序对易学性有很大的影响，但这也不存在唯一的通用法则。不同的类对成员的排序可能是不同的。
最重要的一点，每个类应该以某种逻辑去排序它的成员，维护者应该要能解释这种排序逻辑。比如， 新的方法不能总是习惯性地添加到类的结尾，因为这样就是按时间顺序而非某种逻辑来排序的。
建议文件区块整理
常量声明区 UI控件成员变量声明区 普通成员变量声明区 初始化相关方法区 重载的逻辑方法区 普通逻辑方法区 内部类声明区
当一个类有多个构造函数，或是多个同名方法，这些函数/方法应该按顺序出现在一起，中间不要放进其它函数/方法。
说明：块状结构(block-like construct)指的是一个类，方法或构造函数的主体。需要注意的是，数组初始化中的初始值可被选择性地视为块状结构(4.8.3.1节)。
大括号与if, else, for, do, while语句一起使用，即使只有一条语句(或是空)，也应该把大括号写上。
对于非空块和块状结构，大括号遵循 Kernighan 和 Ritchie 风格 (Egyptian brackets):
左大括号前不换行 左大括号后换行 右大括号前换行 如果右大括号是一个语句、函数体或类的终止，则右大括号后换行; 否则不换行。 例如，如果右大括号后面是else或逗号，则不换行。
示例：
return () -> {
while (condition()) {
method();
}
};
return new MyClass() {
@Override public void method() {
if (condition()) {
try {
something();
} catch (ProblemException e) {
recover();
}
} else if (otherCondition()) {
somethingElse();
} else {
lastThing();
}
}
};Tip:enum类的一些例外。
一个空的块状结构里什么也不包含，大括号可以简洁地写成{}，不需要换行。
例外：如果它是一个多块语句的一部分(if/else 或 try/catch/finally) ，即使大括号内没内容，右大括号也要换行。 示例：
//这是可以接受的
void doNothing() {}
// 这也可以接受
void doNothingElse() {
}
// 这样就接受不了了
try {
doSomething();
} catch (Exception e) {}每当开始一个新的块，缩进增加4个空格，当块结束时，缩进返回先前的缩进级别。缩进级别适用于代码和注释。
每个语句后要换行。
一个项目可以选择一行80个字符或100个字符的列限制，除了下述例外，任何一行如果超过这个字符数限制，必须自动换行。
例外：
1.不可能满足列限制的行(例如，Javadoc中的一个长URL，或是一个长的JSNI方法参考)。 2.package和import语句 3.注释中那些可能被剪切并粘贴到shell中的命令行。
术语说明：一般情况下，一行长代码为了避免超出列限制(80或100个字符)而被分为多行，我们称之为自动换行(line-wrapping)。我们并没有全面，确定性的准则来决定在每一种情况下如何自动换行。很多时候，对于同一段代码会有好几种有效的自动换行方式。
Tip:提取方法或局部变量可以在不换行的情况下解决代码过长的问题
自动换行的基本准则是：更倾向于在更高的语法级别处断开。
1.如果在非赋值运算符处断开，那么在该符号前断开(比如+，它将位于下一行)。
注意：这一点与 Google 其它语言的编程风格不同(如 C++ 和 JavaScript )。 这条规则也适用于以下”类运算符”符号：点分隔符(.)，类型界限中的 &（)，catch 块中的管道符号(catch (FooException | BarException e)
2.如果在赋值运算符处断开，通常的做法是在该符号后断开(比如=，它与前面的内容留在同一行)。这条规则也适用于foreach语句中的分号。
3.方法名或构造函数名与左括号留在同一行。
4.逗号(,)与其前面的内容留在同一行。
自动换行时，第一行后的每一行至少比第一行多缩进8个空格(注意：制表符不用于缩进。见2.3.1节)。当存在连续自动换行时，缩进可能会多缩进不只8个空格(语法元素存在多级时)。一般而言，两个连续行使用相同的缩进当且仅当它们开始于同级语法元素。
Note: 4.6.3水平对齐一节中指出，不鼓励使用可变数目的空格来对齐前面行的符号。
以下情况需要使用一个空行：
1.类内连续的成员之间：字段，构造函数，方法，嵌套类，静态初始化块，实例初始化块。 例外： 两个连续字段之间的空行是可选的，用于字段的空行主要用来对字段进行逻辑分组。
2.在函数体内，语句的逻辑分组间使用空行。
3.类内的第一个成员前或最后一个成员后的空行是可选的(既不鼓励也不反对这样做，视个人喜好而定)。
4.要满足本文档中其他节的空行要求(比如3.3节：import语句)
多个连续的空行是允许的，但没有必要这样做(我们也不鼓励这样做)。
除了语言需求和其它规则，并且除了文字，注释和Javadoc用到单个空格，单个ASCII空格也出现在以下几个地方：
1.分隔任何保留字与紧随其后的左括号(()(如if, for catch等)。
2.分隔任何保留字与其前面的右大括号(})(如else, catch)。
3.在任何左大括号前({)，两个例外：
o @SomeAnnotation({a, b})(不使用空格)。
o String[][] x = foo;(大括号间没有空格，见下面的Note)。
4.在任何二元或三元运算符的两侧。这也适用于以下”类运算符”符号：
o 类型界限中的&()。
o catch块中的管道符号(catch (FooException | BarException e)。
o foreach语句中的分号。
5.在, : ;及右括号())后
6.如果在一条语句后做注释，则双斜杠(//)两边都要空格。这里可以允许多个空格，但没有必要。
7.类型和变量之间：List list。
8.数组初始化中，大括号内的空格是可选的，即new int[] {5, 6}和new int[] { 5, 6 }都是可以的。
Note： 这个规则并不要求或禁止一行的开关或结尾需要额外的空格，只对内部空格做要求。
术语说明：水平对齐指的是通过增加可变数量的空格来使某一行的字符与上一行的相应字符对齐。 这是允许的，但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 unalignedTip: 对齐可增加代码可读性，但它为日后的维护带来问题。
除非作者和reviewer都认为去掉小括号也不会使代码被误解，或是去掉小括号能让代码更易于阅读，否则我们不应该去掉小括号。
枚举常量间用逗号隔开，换行可选。
private enum Answer {
YES {
@Override public String toString() {
return "yes";
}
},
NO,
MAYBE
}没有方法和文档的枚举类可写成数组初始化的格式：
private enum Suit { CLUBS, HEARTS, SPADES, DIAMONDS }由于枚举类也是一个类，因此所有适用于其它类的格式规则也适用于枚举类。
不要使用组合声明，比如int a, b;。
不要在一个代码块的开头把局部变量一次性都声明了(这是c语言的做法)，而是在第一次需要使用它时才声明。 局部变量在声明时最好就进行初始化，或者声明后尽快进行初始化。
数组初始化可以写成块状结构，比如，下面的写法都是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}中括号是类型的一部分：String[] args， 而非 String args[]。
术语说明：switch块的大括号内是一个或多个语句组。
每个语句组包含一个或多个switch标签(case FOO:或default:)，后面跟着一条或多条语句。
与其它块状结构一致，switch块中的内容缩进为2个空格。每个switch标签后新起一行，再缩进2个空格，写下一条或多条语句。
在一个switch块内，每个语句组要么通过break, continue, return或抛出异常来终止，要么通过一条注释来说明程序将继续执行到下一个语句组， 任何能表达这个意思的注释都是OK的(典型的是用// fall through)。这个特殊的注释并不需要在最后一个语句组(一般是default)中出现。
示例：
switch (input) {
case 1:
case 2:
prepareOneOrTwo(); // fall through
case 3:
handleOneTwoOrThree();
break;
default:
handleLargeNumber(input);
}每个switch语句都包含一个default语句组，即使它什么代码也不包含。
注解紧跟在文档块后面，应用于类、方法和构造函数，一个注解独占一行。这些换行不属于自动换行，因此缩进级别不变。
例如：
@Override
@Nullable
public String getNameIfPresent() { ... }例外：单个的注解可以和签名的第一行出现在同一行。 例如：
@Override public int hashCode() { … }应用于字段的注解紧随文档块出现，应用于字段的多个注解允许与字段出现在同一行。 例如：
@Partial @Mock DataLoader loader;参数和局部变量注解没有特定规则。
块注释与其周围的代码在同一缩进级别。它们可以是/*…*/风格，也可以是// …风格。对于多行的/*…*/注释，后续行必须从开始， 并且与前一行的对齐。
/*
* This is // And so /* Or you can
* okay. // is this. * even do this. */
*/注释不要封闭在由星号或其它字符绘制的框架里。
Tip: 在写多行注释时，如果你希望在必要时能重新换行(即注释像段落风格一样)，那么使用/…/。
如果类和成员存在多个限制符，则按Java语言规范中推荐的顺序出现。
public protected private abstract static final transient Volatile synchronized native strictfp
标识符只能使用ASCII字母和数字，因此每个有效的标识符名称都能匹配正则表达式\w+。
包名全部小写，连续的单词只是简单地连接起来，不使用下划线。 采用反域名命名规则，全部使用小写字母。一级包名为com，二级包名为xx（可以是公司或则个人的随便），三级包名根据应用进行命名，四级包名为模块名或层级名。
例如：com.zhiyicx.thinksns.ui
类名都以大驼峰(UpperCamelCase)风格编写。
类名通常是名词或名词短语，接口名称有时可能是形容词或形容词短语。现在还没有特定的规则或行之有效的约定来命名注解类型。
名词，采用大驼峰命名法，尽量避免缩写，除非该缩写是众所周知的， 比如HTML,URL，如果类名称中包含单词缩写，则单词缩写的每个字母均应大写。
| 类 | 描述 | 例如 |
|---|---|---|
| Activity 类 | Activity为后缀标识 | 欢迎页面类WelcomeActivity |
| Adapter类 | Adapter 为后缀标识 | 新闻详情适配器 NewDetailAdapter |
| 解析类 | Parser为后缀标识 | 首页解析类HomePosterParser |
| 工具方法类 | Utils或Manager为后缀标识 | 线程池管理类：ThreadPoolManager日志工具类：LogUtils打印工具类：PrinterUtils |
| 数据库类 | 以DBHelper后缀标识 | 新闻数据库：NewDBHelper |
| Service类 | 以Service为后缀标识 | 时间服务TimeService |
| Receive类 | 以Receiver为后缀标识 | 推送接收JPushReceiver |
| ContentProvider | 以Provider为后缀标识 | |
| 共享基础类 | 以Base开头 | BaseActivity,BaseFragment |
| 测试类 | 它要测试的类的名称开始，以Test结束。 | HashTest 或 HashIntegrationTest |
| 接口（interface） | 接口命名规则与类一样采用大驼峰命名法，多以I开头或者able、ible、er结尾 | interface ILoginView; interface Runnable ;interface Accessible;interface OnclickListener |
注意： 如果项目采用MVP，所有Model、View、Presenter的接口都以I为前缀，不加后缀。
方法名都以 小驼峰(LowerCamelCase) 风格编写。
方法名通常是动词或动词短语。
| 方法 | 说明 |
|---|---|
| initXX() | 初始化相关方法,使用init为前缀标识，如初始化布局initView() |
| isXX() checkXX() | 方法返回值为boolean型的请使用is或check为前缀标识 |
| getXX() | 返回某个值的方法，使用get为前缀标识 |
| handleXX() | 对数据进行处理的方法，尽量使用handle为前缀标识 |
| displayXX()/showXX() | 弹出提示框和提示信息，使用display/show为前缀标识 |
| saveXX() | 与保存数据相关的，使用save为前缀标识 |
| resetXX() | 对数据重组的，使用reset前缀标识 |
| clearXX() | 清除数据相关的 |
| removeXXX() | 清除数据相关的 |
| drawXXX() | 绘制数据或效果相关的，使用draw前缀标识 |
下划线可能出现在JUnit测试方法名称中用以分隔名称的逻辑组件。一个典型的模式是：test_，例如testPop_emptyStack。
并不存在唯一正确的方式来命名测试方法。
常量名命名模式为CONSTANT_CASE，全部字母大写，用下划线分隔单词。这些名字通常是名词或名词短语.
// Constants
static final int NUMBER = 5;
static final ImmutableListNAMES = 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 SetmutableCollection = new HashSet();
static final ImmutableSetmutableElements = ImmutableSet.of(mutable);
static final Logger logger = Logger.getLogger(MyClass.getName());
static final String[] nonEmptyArray = {"these", "can", "change"};非常量字段名以LowerCamelCase风格的基础上改造为如下风格：
基本结构为scopeVariableNameType，
scope：范围
非公有，非静态字段命名以m开头。
公有非静态字段命名以p开头。
静态字段命名以s开头。
公有静态字段（全局变量）命名以g开头。
public static final 字段(常量) 全部大写，并用下划线连起来。
例子：
public class MyClass {
public static final int SOME_CONSTANT = 42;
public int pField;
private static MyClass sSingleton;
int mPackagePrivate;
private int mPrivate;
protected int mProtected;
public static int gField;
}Note: 使用1字符前缀来表示作用范围，1个字符的前缀必须小写，前缀后面是由表意性强的一个单词或多个单词组成的名字，而且每个单词的首写字母大写，其它字母小写，这样保证了对变量名能够进行正确的断句。
Type：类型
考虑到Android中使用很多UI控件，为避免控件和普通成员变量混淆以及更好达意，所有用来表示控件的成员变量统一加上控件缩写作为后缀（文末附有缩写表）。
对于普通变量一般不添加类型后缀，如果统一添加类型后缀，请参考文末的缩写表。
用统一的量词通过在结尾处放置一个量词，就可创建更加统一的变量，它们更容易理解，也更容易搜索。
Note： 如果项目中使用ButterKnife，则不添加m前缀，以LowerCamelCase风格命名。 例如，请使用 mCustomerStrFirst 和 mCustomerStrLast，而不要使用mFirstCustomerStr和mLastCustomerStr。
说明：
集合添加如下后缀：List、Map、Set
数组添加如下后缀：Arr
Note： 所有的VO（值对象）统一采用标准的lowerCamelCase风格编写，所有的DTO（数据传输对象）就按照接口文档中定义的字段名编写。
参数名以LowerCamelCase风格编写
局部变量名以LowerCamelCase风格编写，比起其它类型的名称，局部变量名可以有更为宽松的缩写。
虽然缩写更宽松，但还是要避免用单字符进行命名，除了临时变量和循环变量。
即使局部变量是final和不可改变的，也不应该把它示为常量，自然也不能用常量的规则去命名它。
临时变量
临时变量通常被取名为i，j，k，m和n，它们一般用于整型；c，d，e，它们一般用于字符型。 如： for (int i = 0; i < len ; i++)，并且它和第一个单词间没有空格。
类型变量可用以下两种风格之一进行命名：
单个的大写字母，后面可以跟一个数字(如：E, T, X, T2)。 以类命名方式(5.2.2节)，后面加个大写的T(如：RequestT, FooBarT)。
全部小写，采用下划线命名法，使用名词或名词词组。
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
例如： `include_head.xml、include_bottom.xml、include_title.xml`
全部小写，采用下划线命名法，加前缀区分
命名模式：可加后缀 _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_功能_说明 |
全部小写，采用下划线命名法，加前缀区分。
具体动画采用以下规则： 模块名_逻辑名称 逻辑名称
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 | 中间缩小 |
| 类别 | 命名 | 示例 |
|---|---|---|
| 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 |
命名模式为：view缩写_view的逻辑名称
缩写做后缀，如：tv_username（展示用户名的TextView）
1) @Override：能用则用
只要是合法的，就把@Override注解给用上。除非父类使用了@Deprecated
2) 捕获的异常：不能忽视
除了下面的例子，对捕获的异常不做响应是极少正确的。(典型的响应方式是打印日志，或者如果它被认为是不可能的，则把它当作一个 AssertionError 重新抛出。)
3) 静态成员：使用类进行调用
使用类名调用静态的类成员，而不是具体某个对象或表达式。
```java
Foo aFoo = ...;
Foo.aStaticMethod(); // good
aFoo.aStaticMethod(); // bad
somethingThatYieldsAFoo().aStaticMethod(); // very bad
```
4) Finalizers: 禁用
极少会去重载Object.finalize。
如果它确实是不需要在catch块中做任何响应，需要做注释加以说明(如下面的例子)。
try {
int i = Integer.parseInt(response);
return handleNumericResponse();
} catch (NumberFormatException ok) {
// it's not numeric; that's fine, just continue
}
return handleTextResponse(response);例外：当确保所测试的方法会抛出一个期望中的异常时，就没有必要加注释。
try {
emptyStack.pop();
fail();
} catch (NoSuchElementException expected) {
}Tip: 尽量避免使用finalize。如果你非要使用它，请先仔细阅读和理解Effective Java 第7条款：”Avoid Finalizers”。
Javadoc块的基本格式如下所示：
/**
* Multiple lines of Javadoc text are written here,
* wrapped normally...
*/
public int method(String p1) { ... }或者是以下单行形式：
/** An especially short bit of Javadoc. */当整个Javadoc块能容纳于一行时(且没有Javadoc标记@XXX)，可以使用单行形式。
空行(即，只包含最左侧星号的行)会出现在段落之间和Javadoc标记(@XXX)之前(如果有的话)。
除了第一个段落，每个段落第一个单词前都有标签
，并且它和第一个单词间没有空格。
标准的Javadoc标记按以下顺序出现：@param, @return, @throws, @deprecated,
前面这4种标记如果出现，描述都不能为空。 当描述无法在一行中容纳，连续行需要至少再缩进4个空格。
每个类或成员的Javadoc以一个简短的摘要片段开始。这个片段是非常重要的，在某些情况下，它是唯一出现的文本，比如在类和方法索引中。
这只是一个小片段，可以是一个名词短语或动词短语，但不是一个完整的句子。它不会以 A {@code Foo} is a…或This method returns…开头,它也不会是一个完整的祈使句，如 Save the record…。然而，由于开头大写及被加了标点，它看起来就像是个完整的句子。
Tip:
一个常见的错误是把简单的Javadoc写成 /** @return the customer ID /，这是不正确的。它应该写成/* Returns the customer ID. */。
至少在每个public类及它的每个public和protected成员处使用Javadoc，以下是一些例外：
对于简单明显的方法如getFoo，Javadoc是可选的(即，是可以不写的)。这种情况下除了写”Returns the foo”，确实也没有什么值得写了。
单元测试类中的测试方法可能是不言自明的最常见例子了，我们通常可以从这些方法的描述性命名中知道它是干什么的，因此不需要额外的文档说明。
Tip:
如果有一些相关信息是需要读者了解的，那么以上的例外不应作为忽视这些信息的理由。例如，对于方法名getCanonicalName， 就不应该忽视文档说明，因为读者很可能不知道词语canonical name指的是什么。
如果一个方法重载了超类中的方法，那么Javadoc并非必需的。
对于包外不可见的类和方法，如有需要，也是要使用Javadoc的。如果一个注释是用来定义一个类，方法，字段的整体目的或行为，那么这个注释应该写成Javadoc，这样更统一更友好。
表1 UI控件缩写表
| 控件 | 缩写 | 例子 |
|---|---|---|
| LinearLayout | ll | llFriend或者mFriendLL |
| RelativeLayout | rl | rlMessage或mMessageRL |
| FrameLayout | fl | flCart或mCartFL |
| TableLayout | tl | tlTab或mTabTL |
| Button | btn | btnHome或mHomeBtn |
| ImageButton | ibtn | btnPlay或mPlayIBtn |
| TextView | tv | tvName或mNameTV |
| EditText | et | etName或mNameET |
| ListView | lv | lvCart或mCartLV |
| ImageView | iv | ivHead或mHeadIV |
| GridView | gv | gvPhoto或mPhotoGV |
| 表2 常见的英文单词缩写: |
| 名称 | 缩写 |
|---|---|
| icon | ic （主要用在app的图标） |
| color | cl（主要用于颜色值） |
| divider | di（主要用于分隔线，不仅包括Listview中的divider，还包括普通布局中的线） |
| selector | sl（主要用于某一view多种状态，不仅包括Listview中的selector，还包括按钮的selector） |
| average | avg |
| background | bg（主要用于布局和子布局的背景） |
| buffer | buf |
| control | ctrl |
| delete | del |
| document | doc |
| error | err |
| escape | esc |
| increment | inc |
| infomation | info |
| initial | init |
| image | img |
| Internationalization | I18N |
| length | len |
| library | lib |
| message | msg |
| password | pwd |
| position | pos |
| server | srv |
| string | str |
| temp | tmp |
| window | wnd(win) |
Note: 程序中使用单词缩写原则：不要用缩写，除非该缩写是公认的。