前言

尽管咱们我的项目的代码工夫并不长，也没通过太多人手，但代码的规范性仍然堪忧，目前存在较多的比拟自在的「代码标准」，这十分不利于我的项目的保护，代码可读性也不够高，

此外，客户端和后端的研发模式也齐全不同，后端研发根本都是基于 SOA 思维的，通常一个子系统 3 集体一起保护就曾经是很充沛的人力了，更多时候就是 1 个主力 + 1 个 backup 的人力配置。

而客户端却齐全不同，大家的代码都是互相穿插的，一个模块的代码可能要经验数十人的践踏，所以造成一个统一的开发标准火烧眉毛。

为什么须要统一的代码标准？

外围还是缩小沟通老本，晋升咱们的 Code Review 效率，让咱们的代码更加易于保护。此外，一个统一的代码标准能够造成更少的 bug，也就意味着更节省时间和金钱。

当然，标准是约定的，本系列文字全是笔者多年来博采众长，积攒而成，所以有任何不同意见，欢送评论拍砖。

1. Android 的工具标准

工欲善其事，必先利其器。

因为 Android 根本都基于 Android Studio 进行开发，所以工具标准全副以 Android Studio 为前提。

1. 必须应用最新的稳固版本的 Android Studio 进行开发；
2. 编码格局必须对立为 UTF-8；

3. 删除多余的 import，缩小正告呈现，可利用 AS 的 Optimize Imports（Settings -> Keymap -> Optimize Imports）快捷键，设置本人的爱好。

4. 编辑完 .java、.kt、.xml 等文件后必须格式化（须要在设置好以下几点的前提下）

Reformat Code 的必要性，肯定须要保障 IDE 配置统一为前提，尽可能贴切于 Android Studio 默认。
强烈建议对于比拟长的老代码部分格式化，不全局格式化

• 每行字符数不得超过 160 字符，设置 Editor -> Code Style

• 全副设置为单门路援用，kotlinx.android.synthetic.main 除外。

以上几处设置结束，其余采纳 Android Studio 默认形式，再进行 Reformat Code 快捷键即可。

2. Android 的分包标准

后面强调了工具的对立配置，再利用 Android Studio 自身的性能便可把代码格调变得统一。接下来就带来第二局部：Android 的分包标准。

对于分包，咱们须要达成统一，咱们采纳 PBF 形式，不举荐应用 PBL 形式。

PBF（按性能分包 Package By Feature）
PBL（按层分包 Package By Layer）

PBF 可能不是很好辨别在哪个性能中，不过也比 PBL 要好找很多，且 PBF 与 PBL 相比拟有如下劣势：

• package 内高内聚，package 间低耦合
  哪块要添新性能，只改某一个 package 下的货色，而 PBL 须要改多个 package，十分麻烦。
• package 有公有作用域（package-private scope）
  原则上一个 package 下的不容许其余类拜访都是不应该加上 public 的。
• 很容易删除性能
  统计发现新性能没人用，这个版本那块性能得去掉。如果是 PBL，得从性能入口到整个业务流程把受到牵连的所有能删的代码和 class 都揪出来删掉，一不小心就完蛋。如果是 PBF，好说，先删掉对应包，再删掉性能入口（删掉包后入口必定报错了），完事。
• 高度形象
  解决问题的个别办法是从形象到具体，PBF 包名是对功能模块的形象，包内的 class 是实现细节，合乎从形象到具体，而 PBL 弄反了。PBF 从确定 AppName 开始，依据功能模块划分 package，再思考每块的具体实现细节，而 PBL 从一开始就要思考要不要 dao 层，要不要 com 层等等。
• 只通过 class 来拆散逻辑代码
  PBL 既拆散 class 又拆散 package，而 PBF 只通过 class 来拆散逻辑代码。
• package 的大小有意义了
  PBL 中包的大小有限增长是正当的，因为性能越添越多，而 PBF 中包太大（包里 class 太多）示意这块须要重构（划分子包）。

3. Android 的命名标准

代码中的命名严禁应用拼音与英文混合的形式，更不容许间接应用中文的形式。正确的英文拼写和语法能够让阅读者易于了解，防止歧义。

留神：即便纯拼音命名形式也要防止采纳。但国内通用的名称，可视同英文，比方 toutiao、douyin 等。

3.1 包名

Android 外面有 package 的概念，所以须要约定一下包名命名标准。

包名全副小写，不容许呈现中文、大写字母或者下划线，后面为子模块命名，再依据 PBF 形式进行命名。

3.2 类名

类名都以 UpperCamelCase 格调编写。

类名通常是名词或名词短语，接口名称有时可能是形容词或形容词短语。当初还没有特定的规定或卓有成效的约定来命名注解类型。

名词，采纳大驼峰命名法，尽量避免缩写，除非该缩写是家喻户晓的，比方 HTML、URL，如果类名称中蕴含单词缩写，则单词缩写的每个字母均应大写。

日志工具类：LogUtils（Logger 也可）
打印工具类：PrinterUtils |
| 数据库类 | 性能名 + DBHelper | 新闻数据库：NewsDBHelper |
| 自定义的共享根底类 | Base + 根底 | BaseActivity, BaseFragment |
| 抽象类 | Base / Abstract 结尾 | AbstractLogin |
| 异样类 | Exception 结尾 | LoginException |
| 接口 | able / ible 结尾 / I 结尾 | Runnable, Accessible，ILoginView |

测试类的命名以它要测试的类的名称开始，以 Test 完结。例如：HashTest 或 HashIntegrationTest。

接口（interface）：命名规定与类一样采纳大驼峰命名法，多以 able 或 ible 结尾，如 interface Runnable、interface Accessible。

留神：如果我的项目采纳 MVP，所有 Model、View、Presenter 的接口都以 I 为前缀，不加后缀，其余的接口采纳上述命名规定。

3.3 办法名

办法名都以 lowerCamelCase 格调编写。

办法名通常是动词或动词短语。

3.4 变量命名

这里的变量为狭义的变量，包含了常量、局部变量、全局变量等，它们的根底规定是：

• 类型须要是名词 / 名词短语；
• 采纳 lowerCamelCase 格调；

在具体的变量命名时，会依据该变量的类型不同而附加额定的命名规定：

3.5 资源命名

Android 的资源包含：

资源文件命名为全副小写，采纳下划线命名法。

3.5.1 动画资源文件（anim/ 和 animator/）

安卓次要蕴含属性动画和视图动画，其视图动画包含补间动画和逐帧动画。属性动画文件须要放在 res/animator/ 目录下，视图动画文件需放在 res/anim/ 目录下。命名规定：{模块名_}逻辑名称。

阐明：{} 中的内容为可选，逻辑名称 可由多个单词加下划线组成。例如：refresh_progress.xml、market_cart_add.xml、market_cart_remove.xml。

如果是一般的补间动画或者属性动画，可采纳：动画类型_方向 的命名形式。

例如：

3.5.2 色彩资源文件（color/）

color/ 是专门用于寄存色彩相干资源的文件夹。命名规定：类型{_模块名}_逻辑名称。

阐明：{} 中的内容为可选。例如：sel_btn_font.xml。

色彩资源也能够放于 res/drawable/ 目录，援用时则用 @drawable 来援用，但不举荐这么做，最好还是把两者离开。

3.5.3 图片资源文件（drawable/ 和 mipmap/）

res/drawable/ 目录下放的是位图文件（.png、.9.png、.jpg、.gif）或编译为可绘制对象资源子类型的 XML 文件，而 res/mipmap/ 目录下放的是不同密度的启动图标，所以 res/mipmap/ 只用于寄存启动图标，其余图片资源文件都应该放到 res/drawable/ 目录下。

命名规定：类型 {_模块名}_逻辑名称、 类型{_模块名}_色彩。

阐明：{} 中的内容为可选；类型 能够是可绘制对象资源类型，也能够是控件类型最初可加后缀 _small 示意小图，_big 示意大图。

例如：

如果有多种状态，如按钮选择器：sel_btn_xx.xml，采纳如下命名：

留神：应用 Android Studio 的插件 SelectorChapek 能够疾速生成 selector，前提是命名要标准。

3.5.4 布局资源文件（layout/）

命名规定：类型_模块名 、{模块名_} 类型_逻辑名称。(也采纳 PBF，不便查看，尤其在大我的项目中)

阐明：{} 中的内容为可选。

例如：

3.5.5 布局资源 id 命名

命名规定：{模块名_}_逻辑名_view 缩写（性能），例如：main_search_btn、back_btn。此外，采纳 Kotlinx 间接获取布局文件的时候，id 命名采纳驼峰款式。

阐明：{} 中的内容为可选。参考 GoogleSamples Demo：https://github.com/android/architecture-samples

例如：

3.5.6 菜单资源文件（menu/）

菜单相干的资源文件应放在该目录下。命名规定：{模块名_}逻辑名称

阐明：{} 中的内容为可选。例如：main_drawer.xml、navigation.xml。

3.5.7 colors.xml

<color> 的 name 命名应用下划线命名法，在你的 colors.xml 文件中应该只是映射色彩的名称一个 ARGB 值，而没有其它的。不要应用它为不同的按钮来定义 ARGB 值。

例如，不要像上面这样做：

  <resources>
      <color name="button_foreground">#FFFFFF</color>
      <color name="button_background">#2A91BD</color>
      <color name="comment_background_inactive">#5F5F5F</color>
      <color name="comment_background_active">#939393</color>
      <color name="comment_foreground">#FFFFFF</color>
      <color name="comment_foreground_important">#FF9D2F</color>
      ...
      <color name="comment_shadow">#323232</color>

应用这种格局，会非常容易反复定义 ARGB 值，而且如果利用要扭转基色的话会十分艰难。同时，这些定义是跟一些环境关联起来的，如 button 或者 comment，应该放到一个按钮格调中，而不是在 colors.xml 文件中。

相同，应该这样做：

  <resources>

      <!-- 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>

      <!-- basic colors -->
      <color name="green">#27D34D</color>
      <color name="blue">#2A91BD</color>
      <color name="orange">#FF9D2F</color>
      <color name="red">#FF432F</color>

  </resources>

向利用设计者那里要这个调色板，名称不须要跟 "green"、"blue" 等等雷同。"brand_primary"、"brand_secondary"、"brand_negative" 这样的名字也是齐全能够承受的。像这样标准的色彩很容易批改或重构，会使利用一共应用了多少种不同的色彩变得十分清晰。通常一个具备审美价值的 UI 来说，缩小应用色彩的品种是十分重要的。

留神：如果某些色彩和主题无关，那就独自写一个 colors_theme.xml。

3.5.8 strings.xml

<string> 的 name 命名应用下划线命名法，采纳以下规定：{模块名_}逻辑名称，这样不便同一个界面的所有 string 都放到一起，不便查找。

3.5.9 styles.xml

<style> 的 name 命名应用大驼峰命名法，简直每个我的项目都须要适当的应用 styles.xml 文件，因为对于一个视图来说，有一个反复的外观是很常见的，将所有的外观细节属性（colors、padding、font）放在 styles.xml 文件中。在利用中对于大多数文本内容，最起码你应该有一个通用的 styles.xml 文件，例如：

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

利用到 TextView 中：

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="@string/price"
    style="@style/ContentText"/>

或者你须要为按钮控件做同样的事件，不要进行在那里，将一组相干的和反复 android:xxxx 的属性放到一个通用的 <style> 中。

4. Android 的正文标准

4.1 类正文

每个类实现后应该有作者姓名和联系方式的正文，对本人的代码负责。

/**
 * <pre>
 *     author : nanchen
 *     e-mail : xxx@xx
 *     time   : 2021/01/18
 *     desc   : xxxx 形容
 *     version: 1.0
 * </pre>
 */
public class WelcomeActivity {...}

具体能够在 AS 中本人配制，进入 Settings -> Editor -> File and Code Templates -> Includes -> File Header，输出

/**
 * <pre>
 *     author : ${USER}
 *     e-mail : xxx@xx
 *     time   : ${YEAR}/${MONTH}/${DAY}
 *     desc   :
 *     version: 1.0
 * </pre>
 */

这样便可在每次新建类的时候主动加上该头正文。

4.2 办法正文

每一个成员办法（包含自定义成员办法、笼罩办法、属性办法）的办法头都必须做办法头正文，在办法前一行输出 /** + 回车 或者设置 Fix doc comment（Settings -> Keymap -> Fix doc comment）快捷键，AS 便会帮你生成模板，咱们只须要补全参数即可，如下所示。@param , @return , @throws , @deprecated 这 4 种标记呈现的时候，形容都不能为空。当形容无奈在一行中包容，间断行至多须要再缩进 4 个空格。

    /**
     * Report an accessibility action to this view's parents for delegated processing.
     *
     * <p>Implementations of {@link #performAccessibilityAction(int, Bundle)} may internally
     * call this method to delegate an accessibility action to a supporting parent. If the parent
     * returns true from its
     * {@link ViewParent#onNestedPrePerformAccessibilityAction(View, int, android.os.Bundle)}
     * method this method will return true to signify that the action was consumed.</p>
     *
     * <p>This method is useful for implementing nested scrolling child views. If
     * {@link #isNestedScrollingEnabled()} returns true and the action is a scrolling action
     * a custom view implementation may invoke this method to allow a parent to consume the
     * scroll first. If this method returns true the custom view should skip its own scrolling
     * behavior.</p>
     *
     * @param action Accessibility action to delegate
     * @param arguments Optional action arguments
     * @return true if the action was consumed by a parent
     */
    public boolean dispatchNestedPrePerformAccessibilityAction(int action, Bundle arguments) {for (ViewParent p = getParent(); p != null; p = p.getParent()) {if (p.onNestedPrePerformAccessibilityAction(this, action, arguments)) {return true;}
        }
        return false;
    }

4.3 块正文

块正文与其四周的代码在同一缩进级别。它们能够是 /* ... */ 格调，也能够是 // ... 格调（// 后最好带一个空格）。对于多行的 /* ... */ 正文，后续行必须从 * 开始，并且与前一行的 * 对齐。以下示例正文都是 OK 的。

/*
 * This is okay.
 */

// And so
// is this.

/* Or you can
* even do this. */

正文不要关闭在由星号或其它字符绘制的框架里。

Tip：在写多行正文时，如果你心愿在必要时能从新换行（即正文像段落格调一样），那么应用
/* ... */。

比方：

4.4 全局变量的正文

全局变量的正文款式如下（留神正文之间有空格）：

/**
 * The next available accessibility id.
 */
private static int nextAccessibilityViewId;

/**
 * The animation currently associated with this view.
 */
protected Animation currentAnimation = null;

4.5 其余一些正文

AS 已帮你集成了一些正文模板，咱们只须要间接应用即可，在代码中输出 TODO、FIXME 等这些正文模板，回车后便会呈现如下正文。

// TODO: 17/3/14 须要实现，但目前还未实现的性能的阐明
// FIXME: 17/3/14 须要修改，甚至代码是谬误的，不能工作，须要修复的阐明

4.5 正文必须恪守的标准

4.5.1 不言自明的办法不要加正文。

比方 Item getItem(int index) 是一段自阐明的代码，咱们能够间接从办法的命名就能晓得它是干嘛的，所以不须要减少正文。

4.5.2 提测的代码不应该有 TODO 这样的正文

5. 代码款式标准

5.1 应用规范大括号款式

左大括号不独自占一行，与其后面的代码位于同一行：

class MyClass {int func() {if (something) {// ...} else if (somethingElse) {// ...} else {// ...}
    }
}

咱们须要在条件语句四周增加大括号。例外情况：如果整个条件语句（条件和主体）适宜放在同一行，那么您能够（但不是必须）将其全副放在一行上。例如，咱们承受以下款式：

if (condition) {body();
}

同样也承受以下款式：

if (condition) body();

但不承受以下款式：

if (condition)
    body();  // bad!

5.2 编写简短办法

在可行的状况下，尽量编写短小精炼的办法。咱们理解，有些状况下较长的办法是失当的，因而对办法的代码长度没有做出硬性限度。如果某个办法的代码超出 40 行，请思考是否能够在不毁坏程序结构的前提下对其拆解。

5.3 类成员的程序

这并没有惟一的正确解决方案，但如果都应用统一的程序将会进步代码的可读性，举荐应用如下排序：

1. 常量（Kotlin 伴生对象放在结尾）
2. 字段
3. 构造函数
4. 重写函数和回调
5. 私有函数
6. 公有函数
7. 外部类或接口

例如：

public class MainActivity extends Activity {private static final String TAG = MainActivity.class.getSimpleName();

    private String mTitle;
    private TextView mTextViewTitle;

    @Override
    public void onCreate() {...}

    public void setTitle(String title) {mTitle = title;}

    private void setUpView() {...}

    static class AnInnerClass {}}

如果类继承于 Android 组件（例如 Activity 或 Fragment），那么把重写函数依照他们的生命周期进行排序是一个十分好的习惯，例如，Activity 实现了 onCreate()、onDestroy()、onPause()、onResume()，它的正确排序如下所示：

public class MainActivity extends Activity {
    //Order matches Activity lifecycle
    @Override
    public void onCreate() {}

    @Override
    public void onResume() {}

    @Override
    public void onPause() {}

    @Override
    public void onDestroy() {}
}

5.4 函数参数的排序

在 Android 开发过程中，Context 在函数参数中是再常见不过的了，咱们最好把 Context 作为其第一个参数。

正相反，咱们把回调接口应该作为其最初一个参数。

例如：

// Context always goes first
public User loadUser(Context context, int userId);

// Callbacks always go last
public void loadUserAsync(Context context, int userId, UserCallback callback);

5.5 字符串常量的命名和值

Android SDK 中的很多类都用到了键值对函数，比方 SharedPreferences、Bundle、Intent，所以，即使是一个小利用，咱们最终也不得不编写大量的字符串常量。

过后用到这些类的时候，咱们 必须 将它们的键定义为 static final 字段，并遵循以下批示作为前缀。

阐明：尽管 Fragment.getArguments() 失去的也是 Bundle，但因为这是 Bundle 的罕用用法，所以特意为此定义一个不同的前缀。

例如：

// 留神：字段的值与名称雷同以防止反复问题
static final String PREF_EMAIL = "PREF_EMAIL";
static final String BUNDLE_AGE = "BUNDLE_AGE";
static final String ARGUMENT_USER_ID = "ARGUMENT_USER_ID";

// 与用意相干的项应用残缺的包名作为值的前缀
static final String EXTRA_SURNAME = "com.myapp.extras.EXTRA_SURNAME";
static final String ACTION_OPEN_USER = "com.myapp.action.ACTION_OPEN_USER";

5.6 行长限度

代码中每一行文本的长度都应该不超过 160 个字符。尽管对于此规定存在很多争执，但最终决定仍是以 160 个字符为下限，如果行长超过了 160（AS 窗口右侧的竖线就是设置的行宽开端），咱们通常有两种办法来缩减行长。

• 提取一个局部变量或办法（最好）。
• 应用换行符将一行换成多行。

不过存在以下例外情况：

• 如果备注行蕴含长度超过 160 个字符的示例命令或文字网址，那么为了便于剪切和粘贴，该行能够超过 160 个字符。
• 导入语句行能够超出此限度，因为用户很少会看到它们（这也简化了工具编写流程）。

5.6.1 换行策略

这没有一个精确的解决方案来决定如何换行，通常不同的解决方案都是无效的，然而有一些规定能够利用于常见的状况。

5.6.1.1 操作符的换行

除赋值操作符之外，咱们把换行符放在操作符之前，例如：

int longName = anotherVeryLongVariable + anEvenLongerOne - thisRidiculousLongOne
        + theFinalOne;

赋值操作符的换行咱们放在其后，例如：

int longName =
        anotherVeryLongVariable + anEvenLongerOne - thisRidiculousLongOne + theFinalOne;

5.6.1.2 函数链的换行

当同一行中调用多个函数时（比方应用构建器时），对每个函数的调用应该在新的一行中，咱们把换行符插入在 . 之前。

例如：

Picasso.with(context).load("https://blankj.com/images/avatar.jpg").into(ivAvatar);

咱们应该应用如下规定：

Picasso.with(context)
        .load("https://blankj.com/images/avatar.jpg")
        .into(ivAvatar);

5.6.1.3 多参数的换行

当一个办法有很多参数或者参数很长的时候，咱们应该在每个 , 前面进行换行。

比方：

loadPicture(context, "https://blankj.com/images/avatar.jpg", ivAvatar, "Avatar of the user", clickListener);

咱们应该应用如下规定：

loadPicture(context,
        "https://blankj.com/images/avatar.jpg",
        ivAvatar,
        "Avatar of the user",
        clickListener);

5.6.1.4 RxJava 链式的换行

RxJava 的每个操作符都须要换新行，并且把换行符插入在 . 之前。

例如：

public Observable<Location> syncLocations() {return mDatabaseHelper.getAllLocations()
            .concatMap(new Func1<Location, Observable<? extends Location>>() {
                @Override
                 public Observable<? extends Location> call(Location location) {return mRetrofitService.getLocation(location.id);
                 }
            })
            .retry(new Func2<Integer, Throwable, Boolean>() {
                 @Override
                 public Boolean call(Integer numRetries, Throwable throwable) {return throwable instanceof RetrofitError;}
            });
}

原文链接：https://www.jianshu.com/p/e3a…

文末

您的点赞珍藏就是对我最大的激励！
欢送关注我，分享 Android 干货，交换 Android 技术。
对文章有何见解，或者有何技术问题，欢送在评论区一起留言探讨！