命名规范

代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。正确的英文拼写和语法可以让阅读者易于理解,避免歧义。

注意：即使纯拼音命名方式也要避免采用。但alibaba、taobao、youku、hangzhou等国际通用的名称，可视同英文。

1. 包（Package）

包名全部小写，连续的单词只是简单地连接起来，不使用下划线。
采用反域名命名规则，全部使用小写字母。一级包名是顶级域名，通常为com,edu,gov,net,org等，二级包名以公司或个人来命名，三级包名根据应用进行命名，四级包名为模块名或层级名。

2. 类（Classes）

采用大驼峰命名法，用名词或名词短语命名，每个单词的首字母大写。
尽量避免缩写，除非该缩写是众所周知的， 比如HTML, URL，如果类名称中包含单词缩写，则单词缩写的每个字母均应大写。

3. 接口（interface）

命名规则与类一样采用大驼峰命名法。

• 事件监听器接口命名： On + 监听对象 + Click/Selected+Listener，例如：OnItemClickListener、OnMenuSelectedListener
• 观察者模式接口命名：功能描述 + Observer，例如：NetWorkStateObserver
• 其他接口命名：功能描述 +able/ible，例如：Runnable，Accessible

4. 方法（methods）

采用小驼峰命名法，用动词或动名词命名，除首单词外，其余所有单词的首字母大写。

5. 类的属性

1. 常量 （Constants）

采用下划线命名法，全部大写，单词之间用下划线分开。

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

// 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"};

2. 变量（variables）

采用小驼峰命名法。

• 公有静态字段（全局变量）命名以g开头
• 公有非静态字段命名以p开头
• 静态字段命名以s开头（static，表示静态变量之意）
• 非公有，非静态字段命名以m开头（member，表示成员变量之意，区分于局部变量）。

• UI控件变量

  • 命名规则：逻辑名+UI控件缩写，可参考附录的UI控件缩写表
  • 关于控件缩写放在后面的原因：变量名局限在本类中，关注点更多在于逻辑名称，因此将逻辑名放前面更合适
  • 使用AndroidStudio的插件ButterKnife Zelezny，生成注解非常方便，原生的话可以使用Android Code Generator插件

• 量词变量后缀

  • First 一组变量中的第一个
  • Last 一组变量中的最后一个
  • Next 一组变量中的下一个变量
  • Prev 一组变量中的上一个
  • Cur 一组变量中的当前变量
  • 例如：mCustomerStrFirst mCustomerStrLast
• 集合变量添加如下后缀：List、Map、Set
• 数组变量添加如下后缀：Arr
• 临时变量
  
  • 临时变量通常被取名为i，j，k，m和n，它们一般用于整型
  • c，d，e，它们一般用于字符型

例子：

public class MyClass {
public static final int SOME_CONSTANT = 42;
//常量
private ListView mGoodListLv;
//UI控件变量
public static int gField;
//公有，静态变量以g开头
public int pField;
//公有，非静态变量以p开头
private static MyClass
sSingleton;
//静态变量以s开头
private GoodListAdapter mGoodListAdapter;
private List<Good> mGoodList;
//集合变量
protected int mProtected;
//非公有，非静态变量以m开头
int mPackagePrivate;
//非公有，非静态变量以m开头
private int mPrivate;
//非公有，非静态变量以m开头
}

6. 资源文件命名

必须以全部单词小写，单词间以下划线分割，并且尽可能的使用名词或名词词组。

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

• Activity命名：activity_描述.xml，例如：主页面 activity_main.xml
• Fragment命名：frament_描述.xml，例如：结账模块 frament_main.xml
• Dialog命名：dialog_描述.xml，例如：订单详情对话框 dialog_order_detail.xml
• PopupWindow命名： ppw_描述.xml，例如：包厢预订信息弹窗 ppw_room_book_info.xml
• 列表项命名：item_描述.xml
  
  • 通用列表项：item_city.xml
  • listview：list_item_city.xml
  • gridview：grid_item_city.xml
  • recyclerview：recycler_item_city.xml
  • 自定义类似listview：TabLayout：tab_item_city.xml
• 包含项命名：layout_描述.xml
  
  • 例如：layout_account_login.xml（账号登录布局）、layout_titlebar.xml（标题栏布局）
• 特殊自定义组件/控件
  
  • 通用：common_loading.xml（加载布局）、common_empty.xml（空布局）、common_retry.xml（重试布局）
  • activity：activity_main_loading.xml（主页面加载布局）
  • view：activity_main_good_list_loading.xml（主页面商品列表加载布局）

2. layout中的id命名

• 命名规则：模块名_逻辑名_view缩写，例如：main_search_btn
• 控件id和Java源码文件定义的对应的控件的变量名，应该保持一致

3. 资源文件（图片mipmap及drawable文件夹下）：

• 命名规则： 用途_模块名_逻辑名称_颜色_大小 ，模块名、逻辑名称、颜色、大小至少要有一个
  例如：
  
  • btn_home.png 首页按钮
  • ic_edit.png 编辑图标
  • bg_main.png 主页背景
  • btn_red.png 红色按钮
  • btn_red_big.png 红色大按钮
  • ic_head_small.png 小头像
  • bg_input.png 输入框背景
  • divider_white.png 白色分割线
  • def_good.png 默认的商品图片
  • bg_round_rect_gray.xml 灰色的圆角矩形背景
  • btn_login_selector.xml 登录按钮选择器

• 如果有多种状态，如按钮选择器：btn_xx.xml(selector)

  命名	说明
  btn_xx	整体效果（selector）
  btn_xx_normal	正常情况效果
  btn_xx_pressed	点击时候效果
  btn_xx_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

4. 动画文件（anim文件夹下）

• 具体动画命名规则：模块名_逻辑名称
  
  • 例如：
    
    • refresh_progress，刷新进度条动画
    • shopping_cart_add，购物车添加动画
    • shopping_cart_remove，购物车移除动画
• 普通的tween动画命名规则：动画类型_动画方向
  
  • fade_in，淡入
  • fade_out，淡出
  • push_down_in，从下方推入
  • push_down_out，从下方推出
  • slide_in_from_top，从头部滑动进入
  • zoom_enter，变形进入
  • shrink_to_middle，中间缩小

5. values中name命名

1. colors.xml

colors的name命名使用下划线命名法，命名规则有两种，第一种是构建一个【调色板】。

<resources>
<!-- basic colors -->
<color name="green">#27D34D</color>
<color name="blue">#2A91BD</color>
<color name="orange">#FF9D2F</color>
<color name="red">#FF432F</color>
<!-- grayscale -->
<color name="white">#FFFFFF</color>
<color name="gray_light">#DBDBDB</color>
<color name="gray">#939393</color>
<color name="gray_dark">#5F5F5F</color>
<color name="black">#323232</color>
</resources>

这样命名虽然看起来非常清晰，也不会重复定义ARGB值，但是如果你的应用有多主题的需求，那就很尴尬了。

所以第二种命名规则：模块名称_逻辑名称_用途，不同模块之间用空行隔开。

<resources>
<!-- 通用编辑框 -->
<color name="common_edit_bg">#F8F8F8</color>
<color name="common_edit_text">#000000</color>
<!-- 通用文本框 -->
<color name="common_text_bg">#FFFFFF</color>
<color name="common_text">#94602A</color>
<!-- 通用确认窗口 -->
<color name="confirm_dialog_btn_ok_bg">#DE3838</color>
<color name="confirm_dialog_btn_cancel_bg">#DE3838</color>
<!-- 登录窗口 -->
<color name="login_dialog_btn_text">#FFFFFF</color>
<color name="login_dialog_input_text">#000000</color>
<color name="login_dialog_input_hint">#AD9F8E</color>
</resources>

这样命名的优缺点恰恰与上一种命名规则相反。
综上所述，如果项目没有换肤需求，就采用第一种，如果有则采用第二种。不过讲道理的说，现在没有不代表以后也没有，所以从长远的目光来看，个人建议采用第二种。

2. dimens.xml

dimens的name命名使用下划线命名法，采用以下规则：定义一个空隙间隔和字体大小的“调色板”。 一个好的例子，如下所示：

<resources>
<!-- font sizes -->
<dimen name="font_larger">22sp</dimen>
<dimen name="font_large">18sp</dimen>
<dimen name="font_normal">15sp</dimen>
<dimen name="font_small">12sp</dimen>
<!-- typical spacing between two views -->
<dimen name="spacing_huge">40dp</dimen>
<dimen name="spacing_large">24dp</dimen>
<dimen name="spacing_normal">14dp</dimen>
<dimen name="spacing_small">10dp</dimen>
<dimen name="spacing_tiny">4dp</dimen>
<!-- typical sizes of views -->
<dimen name="button_height_tall">60dp</dimen>
<dimen name="button_height_normal">40dp</dimen>
<dimen name="button_height_short">32dp</dimen>
</resources>

布局时在写margins和paddings时，你应该使用spacing_xxxx尺寸格式来布局，而不是像对待string字符串一样直接写值。 这样写会非常有感觉，会使组织和改变风格或布局是非常容易。

3. strings.xml

strings的name命名使用下划线命名法，采用以下规则：模块名_逻辑名称_用途，不同模块之间用空行隔开。

• 以下为几种常用的用途后缀：
  
  • 标题文字：title
  • 按钮文字：btn
  • 标签文字：label
  • 选项卡文字：tab
  • toast文字：toast
  • 编辑框的提示文字：hint

<resources>
<!-- 通用 -->
<string name="ok">确定</string>
<string name="cancel">取消</string>
<string name="retry">重试</string>
<string name="back">返回</string>
<!-- 登录窗口 -->
<string name="login_dialog_swipe_card_login_tab">刷卡登录</string>
<string name="login_dialog_account_login_tab">账号登录</string>
<string name="login_dialog_account_input_hint">请输入账号</string>
<string name="login_dialog_pwd_input_hint">请输入密码</string>
</resources>

4. styles.xml

style的name命名使用大驼峰命名法，采用以下规则：模块名+逻辑名称。
几乎每个项目都需要适当的使用style文件，因为对于一个视图来说有一个重复的外观是很常见的，将所有的外观细节属性（colors、padding、font）放在style文件中。 在应用中对于大多数文本内容，最起码你应该有一个通用的style文件，例如：

<style name="CommonNormalText">
<item name="android:textColor">@color/text</item>
<item name="android:textSize">@dimen/font_normal</item>
</style>

注释规范

代码注释是架起程序设计者与程序阅读者之间的通信桥梁，最大限度的提高团队开发合作效率。也是程序代码可维护性的重要环节之一。所以我们不是为写注释而写注释。

1 . 文件头注释（如有需要）

文件顶部统一添加版权声明，声明的格式如下：

/**
* Copyright (c) 2017. 海盗的繁华 Inc. All rights reserved.
*/

2 . 类和接口注释

类和接口统一添加javadoc注释，格式如下：

/**
* 类或接口的描述信息
*
* @author ${USER}
* @date ${DATE}
*/

3 . 变量和常量注释

下面几种情况下的常量和变量，都要添加注释说明，优先采用右侧//来注释，若注释说明太长则在上方采用/* … */来注释。

• 接口中定义的所有常量
• 公有类的公有常量
• 枚举类定义的所有枚举常量
• 实体类的所有属性变量

public static final int TYPE_CASH = 1; // 现金券
public static final int TYPE_DEBIT = 2; // 抵扣券
public static final int TYPE_DISCOUNT = 3; // 折扣券
private int id; // 券id
private String name; // 券名称
private String introduce; // 券简介

4 . 方法注释

下面几种方法，都必须添加javadoc注释，说明该方法的用途和参数说明，以及返回值的说明。

• 接口中定义的所有方法
• 抽象类中自定义的抽象方法
• 抽象父类的自定义公用方法
• 工具类的公用方法

建议：除了不言自明的方法外，都应该添加javadoc注释。不言自明的方法指的是如initView()，initData()，getFoo()这种简单明显的方法。

5 .方法内部注释：

控制结构(顺序、选择、循环)，代码做了些什么以及为什么这样做，处理顺序等，特别是复杂的逻辑处理部分，要尽可能的给出详细的注释。

6 .TODO、FIXME注释

对那些临时性的、短期的、够棒但不完美的代码，请使用 TODO 、FIXME注释。
在代码中输入todo、fixme，回车后便会出现如下注释：

// TODO: 2017/3/14 需要实现，但目前还未实现的功能的说明
// FIXME: 2017/3/14
需要修正，甚至代码是错误的，不能工作，需要修复的说明规范

Tip：Android Studio左下角的TODO，可以打开tasks视图查看项目中所有的TODO、FIXME。（功能实现或修正后应及时去掉该注释！）

书写规范

1 . 类成员顺序

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

• 建议使用注释将源文件分为明显的区块，区块划分如下

  • 常量声明区
  • UI控件成员变量声明区
  • 普通成员变量声明区
  • 内部接口声明区
  • onCreate()方法
  • 初始化相关方法区
  • 事件响应方法区
  • 普通逻辑方法区
  • 重载的逻辑方法区
  • 发起异步任务方法区
  • 异步任务回调方法区
  • 生命周期回调方法区（除了onCreate()方法）
  • 内部类声明区

• 类成员排列通用规则

  • 按照发生的先后顺序排列
  • 常量按照使用先后排列
  • UI控件成员变量按照layout文件中的先后顺序排列
  • 普通成员变量按照使用的先后顺序排列
  • 方法基本上都按照调用的先后顺序在各自区块中排列
  • 相关功能作为小区块放在一起（或者封装掉）

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

2 . 空行的使用

将逻辑相关的代码段用空行隔开，以提高可读性。空行也只空一行，不要空多行。在以下情况需用一个空行：

• 类内连续的成员之间：字段，构造函数，方法，嵌套类，静态初始化块，实例初始化块。
  例外： 两个连续字段之间的空行是可选的，用于字段的空行主要用来对字段进行逻辑分组。
• 在函数体内，语句的逻辑分组间使用空行。
• 类内的第一个成员前或最后一个成员后的空行是可选的(既不鼓励也不反对这样做，视个人喜好而定)。
• 多个连续的空行是允许的，但没有必要这样做(我们也不鼓励这样做)。

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的工作并且可能导致更多的合并冲突。

4 . 变量声明

• 一行声明一个变量，不要一行声明多个变量，这样有利于写注释。

private String param1; // 参数1
private String param2; // 参数2

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

5 . 使用快捷键进行代码自动格式化

• Windows：CTRL+ALT+L
• Mac：OPTION+COMMAND+L

附录

表1 UI控件缩写表

表2 常见的英文单词缩写表

程序中使用单词缩写原则：不要用缩写，除非该缩写是约定俗成的。

后记：一直想整一套完整的开发规范，网上也看了很多文章，却始终无法下定决心采用哪一种，所纠结的无非是为什么要采用这样的规范？内心说服不了自己，直到看到以下几篇文章，我才渐渐说服了自己，因为才有这篇文章的诞生。在此特别感谢以下几篇文章的作者。

参考

Android编码规范之命名规则
Android技术积累:开发规范
Android开发规范（updating）
Android 编码规范
android开发规范文档
Google Java编程风格指南

最后

以上就是忧虑香烟为你收集整理的Android开发规范命名规范注释规范书写规范附录参考的全部内容，希望文章能够帮你解决Android开发规范命名规范注释规范书写规范附录参考所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。