Android 编码规范

Posted 2020-09-20 mfmdaoyou

一、命名规范

1.1包命名

命名规则：一个唯一包名的前缀总是所有小写ASCII字母而且是一个顶级域名，一般是com,edu,gov,mil,net,org等。

规约：以公司为准。通常是com.公司名.项目名称缩写.模块名或层级名称

1.2类和接口命名

命名规则：类名是一个名词。採用大写和小写混合的方式。每一个单词的首字母大写。避免使用缩写词。除非该缩写词被更广泛使用，如URL,html等。

                    接口命名，以大写字母I开头。每一个单词的首字母大写。

1.3方法命名

命名规则：方法名是一个动词。採用大写和小写混合的方式，第一个单词首字母小写。其后全部单词的首字母大写

                   1.3.1 类的获取方法（一般具有返回值）一般要求在被訪问的字段名前加上get。

一般来说，get前缀方法返回的是单个值。find方法返回的是列表值。

                   1.3.2类的设置方法（一般返回值为void）被訪问字段名前面加上set

                   1.3.3类的布尔型的推断方法一般要求方法名使用单词is或has做前缀，或者使用具有逻辑意义的单词，比如equal或equals。

                   1.3.4类的普通方法一般採用完整的英文描写叙述说明成员方法功能，第一个单词尽可能採用动词。首字母小写

                   1.3.5构造方法应该用递增的方式写即參数多的写在后面。

1.4变量命名

命名规则：第一个单词的首字母小写。其后单词的首字母大写。变量名不应下面划线或美元符号开头，虽然这在语法上是同意的。尽量避免单个字符的变量名。除非是一次性的暂时变量。暂时变量通常被取名为 i，j。k。m 和 n，它们一般用于整型；c。d，e。它们一般用于字符型。变量命名不同意出现无意义的单词。

1.5成员变量命名

同变量命名，但要在成员变量前加入m字样，后面字母以大写开头，比方mEditHours。

静态变量前加入s字样。后面字母以大写开头，比方sEditTime。

1.6常量命名

命名规则：类常量的声明，应该所有大写，单词间用下划线隔开。

1.7异常命名

规则：自己定义异常的命名必须以Exception为结尾。以明白标示为一个异常。

1.8Layout命名

规约：layout xml的命名必须以所有单词小写，单词间下面划线切割，而且使用名词或名词词组，即使用模块名_功能名称来命名。

1.9 ID命名

规约：layout中所使用的id必须以所有单词小写。单词间下面划线切割，而且使用名词或名词词组，而且要求可以通过id直接理解当前组件要实现的功能。

1.10资源命名

规约：layout中所使用的所有资源（如drawable,style等）命名必须以所有单词小写。单词间下面划线切割，而且尽可能的使用名词或名词组，即使用模块名_用途来命名。假设为公共资源。如切割线等，则直接用用途来命名。

二、凝视规范

释与代码的比例要求为30%，凝视语言必须准确、易懂、简洁。

Java程序有两类凝视：实现凝视(implementationcomments)和文档凝视(document comments)。实现凝视是使用/*...*/和//界定的凝视。文档凝视(被称为"doc comments")由/**...*/界定。文档凝视能够通过javadoc工具转换成HTML文件。

2.1 文件凝视

源文件头部应进行凝视，列出：版权说明、版本、模块目的/功能、作者、生成日期、改动日志等。

文件头模板：

/**  

 * @Title: ${file_name}

 * @Package: ${package_name}

 * @Description: ${todo}(用一句话描写叙述该文件做什么)

 * Copyright: 

 * Company: 

 *

 * @author ${user}

 * @date ${date} ${time}

 * @version V1.0

 */

说明：文件描写叙述一项描写叙述本文件的内容、功能、内部各部分之间的关系及本文件与其他文件关系等。

2.2类凝视

每个类都要包括例如以下格式的凝视，以说明当前类的功能等。

/**

 * @ClassName: ${type_name}

 * @Description: ${todo}(这里用一句话描写叙述这个类的作用)

 * @author ${user}

 * @date ${date} ${time}

 *

 * ${tags}

 */

2.3方法凝视

每个public方法都要包括例如以下格式的凝视，包括当前方法的用途，当前方法參数的含义，当前方法返回值的内容和抛出异常的列表。

/**

 * @Title: ${enclosing_method}

 * @Description: ${todo}(这里用一句话描写叙述这种方法的作用)

 * @param: ${tags} 參数名称

 * @return: ${return_type} 返回类型

 * @throws

 */

2.4类成员和变量凝视

成员变量和常量须要使用java doc形式的凝视，以说明当前变量或常量的含义。

/**

 * @Fields ${field}: ${todo}(用一句话描写叙述这个变量表示什么)

 */

2.5代码凝视

        2.5.1改动代码时应改动对应的凝视

        2.5.2凝视应与其描写叙述的代码相近，不可放在以下，如放于上方则需与其上面的代码用空行隔开。

        2.5.3对数据结构的凝视应放在其上方相邻位置。不可放在以下。对结构中的每一个域的凝视放在此域的右方。

        2.5.4帮助读者理解代码，防止不是必需的反复凝视信息。

        2.5.5.当代码段较长，特别是多重嵌套时。凝视能够使代码更清晰，更便于阅读。

2.6改动已有类的凝视

改动已有类时须要加入修订记录，例如以下。空一行后加入修订记录、改动内容、Review记录三行。

2.7改动代码凝视

2.8XML凝视

规约：假设当前layout 或资源须要被多处调用，或为公共使用的layout（若list_item）。则须要在xml写明凝视。要求凝视清晰易懂。

2.9Code Review凝视

2.10其它凝视

方法内部的凝视假设须要多行使用/*…… */形式，假设为单行是用//……形式的凝视。

不要再方法内部使用 java doc 形式的凝视“/**……**/”，简单的区分方法是，java doc形式的凝视在 eclipse中为蓝色，普通凝视为绿色。

三、代码风格

3.1缩进

规约：不同意使用Tab进行缩进。使用空格进行缩进。推荐缩进为4空格。

3.2空行

下列情况应该总是使用空行：

1、一个源文件的两个片段(section)之间

2、类声明和接口声明之间

3、两个方法之间

4、方法内的局部变量和方法的第一条语句之间

5、一个方法内的两个逻辑段之间，用以提高可读性 

规约：通常在变量声明区域之后要用空行分隔。常量声明区域之后要有空行分隔。方法声明之前要有空行分隔。

3.3行宽

无特别规定，由于如今的显示器都比較大，所以推荐使用120进行设置。

四、规范约定

4.1方法

一个方法尽量不要超过15行，假设方法太长，说明当前方法业务逻辑已经很复杂，那么就须要进行方法拆分，保证每一个方法仅仅作一件事。

4.2參数与返回值

一个方法的參数尽可能的不要超过4个。

尽可能不要使用null，替代为异常或者使用空变量如返回 List 则能够使用Collections.emptyList()。

4.3幽灵数字（參数与返回值）

代码中不同意出现单独的数字。字符！假设须要使用数字或字符。则将它们依照含义封装为静态常量！（for语句中除外）

4.4控制语句

推断中如有常量，则应将常量置于推断式的右側。

尽量不使用三目条件的嵌套。

全部if 语句必须用{}包含起来，即便是仅仅有一句。

4.5异常捕获

若有finally 子句。则不要在try 块中直接返回，亦不要在finally 中直接返回。

4.6訪问控制

五、约定俗成

5.1变量赋值

避免在一个语句中给多个变量赋同样的值。

不要将赋值运算符用在easy与相等关系运算符混淆的地方。

不要使用内嵌(embedded)赋值运算符试图提高执行时的效率，这是编译器的工作。

5.2圆括号

5.3返回值

设法让你的程序结构符合目的。

5.4二元表达式

假设一个包括二元运算符的表达式出如今三元运算符" ? : "的"?

"之前。那么应该给表达式添上一对圆括号。

六、21种代码坏味道

1.Duplicated Code  反复代码

2.Long Method  过长函数

3.Large Class   过大的类

4.Divergent Change   发散式变化

5.Shotgun Surgery     散弹式改动

6.Feature Envy   依赖情结

7.Data Clumps  数据泥团

8.Primitive Obsession    基本类型偏执

9.Switch Statement    多分支选择语句

10.Parallel Inheritance Hierarchies   平行继承体系

11.Lazy Class   冗赘类

12.Speculative Generality  夸夸其谈未来性

13.Temporary Field 令人迷惑的临时值域

14.Message Chain  过度耦合的消息链

15.Middle Man  中间转手人

16.Inappropriate Intimacy   狎昵关系

17.Alternative Classes with Different Interfaces 异曲同工的类

18.Incomplete Library Class  不完好的程序类库

19.Data Class   纯粹的数据类

20.Refused Bequest   被拒绝的遗赠

21.Comments   过多的凝视