Question

无规矩不成方圆。

一个项目必须有统一的命名规范，只有这样，才像是一个团队做的产品。命名规范有以下几点需要注意：

首先，命名规范不能反人类。

我曾经见过有的Team Leader这样为Acitivty设计命名规范：

PersonActivityAddCustomer.java

我看过他们团队的项目，所有的Activity全都是上述这种“模块名+Activity+页面名”的命名方式。我很奇怪的是，为什么不设计成以下方式呢，如图4-1所示。

图4-1　Activity的命名规范

这就涉及人生观、价值观和审美观了，作为Team Leader，不能因为自己的癖好，制定出一些变态的规范，而让其他团队成员跟着受罪。

其次，要望文而知义，清晰准确。比如说登录页面的登录按钮，命名时就不能像button1这样随心所欲，要类似于login_button（资源文件）或btnLogin（java代码中的按钮实例）这样的名称。

此外，遇到MyGridView之类的命名，就可以把创建该文件的同学拉出去打80大板了，而且要肚皮朝上的那种打法。

最后，命名规范千万别制定太多，多了会让人烦，没人看，更没人遵守。要做到简单易记，适可而止。

下面说点具体的规则：

1）Java类文件命名规范。

·Activity命名规范：以Activity作为后缀。比如说PersonActivity。

·Adapter命名规范：以Adapter作为后缀。比如说PersonAdapater。

·Entity命名规范：大多以Entity作为后缀。比如说PersonEntity。值得注意的是，User是全局变量，不算是实体，不受此约束。

2）资源文件命名规范。

·layout目录下的文件命名规范：

·页面布局文件。以act_为前缀，以Activity所在的Package作为中缀，以Activity的名称（去掉Activity后缀）作为后缀。注意都是小写。

·例如，对于Person这个模块下的AddCustomerActivity，它的layout文件就应该是：act_person_addcustomer.xml。

·ListView中的item布局文件。以item_作为固定前缀，列表项的名称为后缀。注意都是小写。例如，某个页面下有一个用户列表，控件名为lvUserList，那么item的layout就应该是：item_lvUserList.xml。

·Dialog布局文件。

以dlg_作为固定前缀，Dialog的功能名称为后缀。注意都是小写，例如：dlg_hint.xml。

·drawable目录下文件命名规范。drawable目录下的资源，大部分是图片，此外，还有一部分xml文件，用于Selector。但无论是图片，亦或Selector文件，都应该遵守下述命名规范：

·对于只在一个页面使用的资源，就以该页面的名称作为前缀。

·对于只在一个模块下多个页面使用的资源，就以该模块的名称作为前缀。

·对于在各个模块、各个页面都有可能使用的资源，比如说上导航、下导航，以common作为前缀。

3）Java类中控件对象的命名规范。

控件类型缩写+控件的逻辑名称（首字母大写），比如登录按钮，就可以命名为btnLogin。

表4-1列出了一些常用控件的缩写。

表4-1　常用控件的缩写

4）Layout中控件对象的命名规范。

这里我建议，与Activity中相对应的控件名称保持一致。这样的好处是可以迅速copy-paste出以下代码而杜绝任何的潜在错误：

Button btnLogin = (Button)findViewById(R.id.btnLogin);

但是这样做与传统Android的命名规范就不一致了，至少违反了2条：不应该出现大写字母，btn和Login之间没有以下划线进行连接，以下的命名才是中规中矩的：

Button btnLogin = (Button)findViewById(R.id.sign_in_button);

我认为以上两种命令方式都是可行的，只要认定其中一种并坚持用下去，就是我们需要的规范，只要不反人类即可。

5）strings.xml中常量的命名规范。

因为这些值大多在Layout中的控件上使用，所以以该常量所在的Activity名称作为前缀，后面接控件名称，再后面就自由发挥了，比如登录页面的登录按钮上显示的文字，就可以命名为：loginActivity_btnLogin_text。

另一种使用场景则是在Java代码中使用，可能出现在Activity中，也可能出现在工具类Utils中，这时候，如果是和具体Activity相关，那么规则和上面的一样，以所在的Activity名称作为前缀，如果涉及和公共模块和控件相关，就以common_作为前缀。

strings.xml的规则可以灵活一些。我们甚至可以将其按照模块拆分为多个strings文件，只要resoures标签下都是string标签就行，编译打包时会自动将同类文件进行合并，如图4-2所示。

图4-2　strings.xml的命名规范

这样做的好处是，各个模块维护各自的strings.xml。但为常量命名时就一定要以模块名作为前缀了，不然很容易产生重名的情况，从而编译报错。

6）常量命名。

这一点遵守Java的命名规范，即只能包含字母和下划线_，字母全部大写，单词之间用下划线_隔开。

关于命名规范的事情，可以写十几页密密麻麻的规则，我这里只提到最关键的几点。其他的，要么是不重要，要么是使用场景少，所以都可以自由发挥。

记住，命名规范的作用在于：

·好的文件命名规范，让几千个文件分门别类的放在好找的位置。

·好的对象命名规范，让整个项目的代码风格整齐一致。

切记，不能为了规范而规范，网上的各种规范不胜枚举，让人眼花缭乱，但是过多的规范，会让App这个轻量级的应用背上越来越沉重的包袱，举步维艰。

制定一套切实可行、易于遵守的命名规范，是每个Team Leader的必备技能。