开发规范

作者: A_si | 来源:发表于2017-02-15 15:07 被阅读58次

https://jeroenmols.com/blog/2016/03/07/resourcenaming/

书写规范

1. 编码方式统一用UTF-8. Android Studio默认已是UTF-8，只要不去改动它就可以了。

2. 缩进统一为4个空格，将Tab size设置为4则可以保证tab键按4个空格缩进。另外，不要勾选上Use tab character，可以保证切换到不同tab长度的环境时还能继续保持统一的4个空格的缩进样式。

3. 花括号不要单独一行，和它前面的代码同一行。而且，花括号与前面的代码之间用一个空格隔开。

public void method() { // Good 

    } 

public void method()
{ // Bad
}  

public void method(){ // Bad

}

4. 空格的使用

if、else、for、switch、while等逻辑关键字与后面的语句留一个空格隔开。

// Good
if (booleanVariable) {
    // TODO while booleanVariable is true
} else {
    // TODO else
}

// Bad
if(booleanVariable) {
    // TODO while booleanVariable is true
}else {
    // TODO else
}

运算符两边各用一个空格隔开。

int result = a + b; //Good, = 和 + 两边各用一个空格隔开
int result=a+b; //Bad,=和+两边没用空格隔开

方法的每个参数之间用一个空格隔开。

public void method(String param1, String param2); // Good，param1后面的逗号与String之间隔了一个空格
method(param1, param2); // Good，方法调用时，param1后面的逗号与param2之间隔了一个空格
method(param1,param2); // Bad，没有用一个空格隔开

5. 空行的使用

将逻辑相关的代码段用空行隔开，以提高可读性。空行也只空一行，不要空多行。在以下情况需用一个空行：
两个方法之间
方法内的两个逻辑段之间
方法内的局部变量和方法的第一条逻辑语句之间
常量和变量之间

6. 当一个表达式无法容纳在一行内时，可换行显示，另起的新行用8个空格缩进。

someMethod(longExpression1, longExpression2, longExpression3,  
        longExpression4, longExpression5);

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

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

8. 行宽设置为100，设置格式化时自动断行到行宽位置。

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

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

10. 一个方法最多不要超过40行代码。

11. 范围型的常量用枚举类定义，而不要直接用整型或字符，这样可以减少范围值的有效性检查。

// 用枚举类定义，Good
public enum CouponType {
    // 现金券
    @SerializedName("1")
    CASH,

    // 抵用券
    @SerializedName("2")
    DEBIT,

    // 折扣券
    @SerializedName("3")
    DISCOUNT
}

// 用整型定义，Bad
public static final int TYPE_CASH = 1; // 现金券
public static final int TYPE_DEBIT = 2; // 抵扣券
public static final int TYPE_DISCOUNT = 3; // 折扣券

Android中实现枚举的方案选择

12. 文字大小的单位统一用sp，元素大小的单位统一用dp。（我们项目文字还是沿用dp）

13. 应用中的字符串统一在strings.xml中定义，然后在代码和布局文件中引用。

14. 颜色值统一在colors.xml中定义，然后在代码和布局文件中引用。另外，不要在代码和布局文件中引用系统的颜色，除了透明。

命名规范

1. 包命名

域名反写+项目名称+模块名称，全部单词用小写字母。例如，V视角项目的Model模块包名如下：
com.vpgame.eric.vperspectives.model

2. 类和接口命名

使用大驼峰规则，用名词或名词词组命名，每个单词的首字母大写。以下为几种常用类的命名：

activity类，命名以Activity为后缀，如：LoginActivity
fragment类，命名以Fragment为后缀，如：ShareDialogFragment
service类，命名以Service为后缀，如：DownloadService
adapter类，命名以Adapter为后缀，如：CouponListAdapter
工具类，命名以Util为后缀，如：EncryptUtil
模型类，命名以BO为后缀，如：CouponBO
接口实现类，命名以Impl为后缀，如：ApiImpl

3. 方法命名

使用小驼峰规则，用动词命名，第一个单词的首字母小写，其他单词的首字母大写。以下为几种常用方法的命名：

初始化方法，命名以init开头，例：initView
按钮点击方法，命名以to开头，例：toLogin
设置方法，命名以set开头，例：setData
具有返回值的获取方法，命名以get开头，例：getData
通过异步加载数据的方法，命名以load开头，例：loadData
布尔型的判断方法，命名以is或has，或具有逻辑意义的单词如equals，例：isEmpty

4. 控件缩写

控件	缩写	控件	缩写
TextView	tv	EditText	edt
Button	btn	ImageButton	ibtn
ImageView	img	ListView	list
RadioGroup	RadioButton	RadioButton	rbtn
ProgressBar	ProgressBar	SeekBar	seek
CheckBox	chk	Spinner	spinner
TableLayout	tl	TableRow	trow
LinearLayout	ll	RelativeLayout	rl
ScrollView	sv	SearchView	search
TabHost	th	TabWidget	tw

5. 常量命名

全部为大写单词，单词之间用下划线分开。
public final static int PAGE_SIZE = 20;

6. 变量命名

{范围描述+}意义描述+类型描述的组合，用驼峰式，首字母小写。
private TextView tvHeaderTitle;

7. 控件id命名

控件缩写{范围}意义，范围可选，只在有明确定义的范围内才需要加上。

<!-- 这是标题栏的标题 -->
<TextView
    android:id="@+id/tv_header_title"
    ... />

<!-- 这是登录按钮 -->
<Button
    android:id="@+id/btn_login"
    ... />

8. layout命名

组件类型{范围}功能，范围可选，只在有明确定义的范围内才需要加上。以下为几种常用的组件类型命名：

activity_{范围_}功能，为Activity的命名格式
fragment_{范围_}功能，为Fragment的命名格式
dialog_{范围_}功能，为Dialog的命名格式
item_{范围_}功能，为列表的item命名格式
我们项目是组件化开发需要加上module类型前缀，举例：
market_item__pro_deal.xml //module类型>market/组件类型>item/范围>pro/功能>deal

9. strings的命名

类型{范围}功能，范围可选。以下为几种常用的命名：

页面标题，命名格式为：title_页面
选项卡文字，命名格式为：tab_选项卡文字
消息框文字，命名格式为：toast_消息
编辑框的提示文字，命名格式为：hint_提示信息
图片的描述文字，命名格式为：desc_图片文字
对话框的文字，命名格式为：dialog_文字
menu的item文字，命名格式为：action_文字
提示文字，命名格式为：tips_文字

10. colors的命名

前缀{控件}{范围}{_后缀}，控件、范围、后缀可选，但控件和范围至少要有一个。

背景颜色，添加bg前缀
文本颜色，添加text前缀
分割线颜色，添加div前缀
区分状态时，默认状态的颜色，添加normal后缀
区分状态时，按下时的颜色，添加pressed后缀
区分状态时，选中时的颜色，添加selected后缀
区分状态时，不可用时的颜色，添加disable后缀
多种状态的，添加selector后缀

11. drawable的命名

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

用途模块名逻辑名称
用途模块名颜色
用途_逻辑名称
用途_颜色
说明：用途也指控件类型（具体见UI控件缩写表）
图标类，添加ic前缀
背景类，添加bg前缀
分隔类，添加div前缀
默认类，添加def前缀
区分状态时，默认状态，添加normal后缀
区分状态时，按下时的状态，添加pressed后缀
区分状态时，选中时的状态，添加selected后缀
区分状态时，不可用时的状态，添加disable后缀
多种状态的，添加selector后缀（一般为ListView的selector或按钮的selector）
shape文件，颜色或者圆角的，添加后缀
例如：

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// 白色分割线

12. 动画文件命名

动画类型_动画方向。

fade_in，淡入
fade_out，淡出
push_down_in，从下方推入
push_down_out，从下方推出
slide_in_from_top，从头部滑动进入
zoom_enter，变形进入
shrink_to_middle，中间缩小

注释规范

1. 文件头注释

2. 类和接口注释

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

* 
 * @Description:  $desc$
 * @author: $user$
 * @data:  $date$  $time$
 * @version: 1.0
 */

3. 方法注释

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

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

/**
 * 登录
 *
 * @param loginName 登录名
 * @param password  密码
 * @param listener  回调监听器
 */
public void login(String loginName, String password, ActionCallbackListener<Void> listener);

4. 变量和常量注释

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

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

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;      // 券简介

5. 弃用注释

弃用的方法，常量，类，都要用*@deprecated *注释。例如：

弃用类

分包

1.分包分析

按照功能分可能你不是很好区分在哪个功能中，不过也比你按照层区分要好找很多。

具体可以参考这篇博文～Package by features, not layers：

https://medium.com/@cesarmcferreira/package-by-features-not-layers-2d076df1964d#.mp782izhh

当然，我们大谷歌也有相应的sample～iosched

https://github.com/google/iosched/tree/master/android/src/main/java/com/google/samples/apps/iosched

其结构很值得学习

2.常见分包方式对比

PBF(按功能分包Package By Feature)与PBL(按层分包Package By Layer)相比较有如下优势：

package内高内聚，package间低耦合

哪块要添新功能，只改某一个package下的东西；

按class职能分层（PBL）降低了代码耦合，但带来了package耦合，要添新功能，需要改model、dbHelper、view、service等等，需要改动好几个package下的代码，改动的地方越多，越容易产生新问题，不是吗？

按功能分包（PBF），featureA相关的所有东西都在featureA包，feature内高内聚高度模块化，不同feature之间低耦合，相关的东西都放在一起，还好找

package有私有作用域（package-private scope）

你负责开发这块功能，这个目录下所有东西都是你的；

PBL的方式是把所有工具方法都放在util包下，小张开发新功能时候发现需要一个xxUtil，但它又不是通用的，那应该放在哪里？

没办法，按照分层原则，我们还得放在util包下，好像不太合适，但放在其它包更不合适，功能越来越多，util类也越定义越多。后来小李负责开发一块功能时发现需要一个xxUtil，同样不通用，去util包一看，怎么已经有了，而且还没法复用，只好放弃xx这个名字，改为xxxUtil……因为PBL的package没有私有作用域，每一个包都是public（跨包方法调用是很平常的事情，每一个包对其它包来说都是可访问的）

如果是PBF，小张的xxUtil自然放在feautreA下，小李的xxUtil在featureB下，如果觉得util好像是通用的，就去util包看看要不要把工具方法添进xxUtil，class命名冲突没有了；

PBF的package有私有作用域，featureA不应该访问featureB下的任何东西（如果非访问不可，那就说明接口定义有问题）

很容易删除功能

统计发现新功能没人用，这个版本那块功能得去掉

如果是PBL，得从功能入口到整个业务流程把受到牵连的所有能删的代码和class都揪出来删掉，一不小心就完蛋；
如果是PBF，好说，先删掉对应包，再删掉功能入口（删掉包后入口肯定报错了），完事。

高度抽象

解决问题的一般方法是从抽象到具体，PBF包名是对功能模块的抽象，包内的class是实现细节，符合从抽象到具体，而PBL弄反了；

PBF从确定AppName开始，根据功能模块划分package，再考虑每块的具体实现细节，而PBL从一开始就要考虑要不要dao层，要不要com层等等

只通过class来分离逻辑代码

PBL既分离class又分离package，而PBF只通过class来分离逻辑代码
没有必要通过package分离，因为PBL中也可能出现尴尬的情况：
├─service
│MainServ.java
按照PBL，service包下的所有东西都是Controller，应该不需要Serv后缀，但实际上通常为了码起来方便，直接import service包，Serv后缀是为了避免引入的class和当前包下的class命名冲突。

当然，不用后缀也可以，得写清楚包路径，比如new net.ayqy.service.Main()，麻烦；而PBF就很方便，无需import，直接new MainServ()即可。

package的大小有意义了

PBL中包的大小无限增长是合理的，因为功能越添越多；而PBF中包太大（包里class太多）表示这块需要重构（划分子包）。

结束语

这份开发规范说明比较细，也许还不是非常完整，也许有的不符合个人习惯，请大家求同存异，产出一份约束规范，并按照实施，将大大提高代码的可读性和维护性。