Android编码规范

使用Android studio作为集成开发环境

对于编辑器，每个人都有自己的选择，让编辑器根据工程结构和构建系统高效运作，是每个人的责任。

推荐使用Android Studio，由谷歌开发，并且最接近Gradle，默认使用最新的工程结构。相比较而言Eclipse ADT使用旧的工程结构和Ant作为构建系统，它不仅需要繁琐的配置，而且gardle和adb命令行同样需要学习成本。

使用Gradle构建项目

默认编译环境使用Gradle。Ant不仅有限制而且操作方式非常繁琐，使用Gradle编译，可以轻松实现以下几点：

1. 构建App的不同版本，在debug和release之间轻松切换。
2. 快速制作简单的脚本任务
3. 轻松下载和管理依赖库
4. 能够方便的按照要求定制Keystore

另外值得一提的是，如果你想更快的构建小规模可重用程序模块，可以采用Facebook Buck，与传统Android编译工具相比，Buck凭借多核及并行技术，极大加速了Android工程的编译速度，并且在多次编译中，它会对未变动的模块进行标记，从而以增量式编译的方式进一步提高构建速度。

项目结构

废弃过时的Ant & Eclipse ADT工程结构，统一使用新的Gradle & Android Studio的工程结构。

要使用Android studio结构：

new-link-structure
├─ library-imsdk
├─ app
│  ├─ libs
│  ├─ src
│  │  ├─ androidTest
│  │  │  └─ java
│  │  │     └─ com/im/project
│  │  └─ main
│  │     ├─ java
│  │     │  └─ com/im/project
│  │     ├─ res
│  │     └─ AndroidManifest.xml
│  ├─ build.gradle
│  └─ proguard-rules.pro
├─ build.gradle
└─ settings.gradle

不使用Eclipse结构：

old-link-structure
├─ assets
├─ libs
├─ res
├─ src
│  └─ com/im/project
├─ AndroidManifest.xml
├─ build.gradle
├─ project.properties
└─ proguard-rules.pro

通过比较可见Android studio的项目结构更加清晰，强调了Gradle概念。其中library-imsdk是app所依赖的module。

签名配置

发布release版本的时候，必须确认SigningConfigs的保密性：

创建一个不加入版本控制系统的gradle.properties文件，或者记录在本地的local.properties中。

KEYSTORE_PASSWORD=storePassword
KEY_PASSWORD=keyPassword

上面提到的两个文件会被gradle自动引入，因此可以在buld.gradle中直接引用，例如：

signingConfigs {
    release {
        try {
            storeFile file("myapp.keystore")
            storePassword KEYSTORE_PASSWORD
            keyAlias "storeKey"
            keyPassword KEY_PASSWORD
        }
        catch (ex) {
            throw new InvalidUserDataException("You should define KEYSTORE_PASSWORD and KEY_PASSWORD in gradle.properties.")
        }
    }
}

不采用以下示例方式，因为这会导致敏感信息的泄露：

signingConfigs {
    release {
        storeFile file("myapp.keystore")
        storePassword "storePassword"
        keyAlias "storeKey"
        keyPassword "keyPassword"
    }
}

使用Maven依赖代替jar包导入

如果在项目中明确使用jar文件，那么它们可能成为永久的版本，如2.1.1。而且很容易陷入频繁更新jar包的繁琐工作中，Maven很好的解决了这个问题，这也是 Gradle构建中推荐的使用方式，例如：

dependencies {
      /*ReactiveX Library*/
      compile 'io.reactivex:rxjava:1.1.3'
      compile 'io.reactivex:rxandroid:1.1.0'
}

或者，在不确定该library最新版本的前提下，可以指定版本范围，如2.1.+,随后Gradle会优先加载Maven仓库中该library的最新版本。

命名规范

Java文件

参考源码命名规则，对Java类文件使用驼峰命名法。

对于继承自Android组件的类来说，类名应该以这个组件的类型作后缀，如：

XML文件

资源等.xml文件要采用小写字母_下划线的组合形式。

Drawable相关

• Drawable文件建议命名方式：

• icon文件建议命名方式：

• selector states文件建议命名方式：

Layout相关

• Layout文件建议命名方式：

布局文件应该与Android组件的命名相匹配，以组件类型作为前缀，并且能够清晰的表达意图。例如：如果为SignInActivity创建一个布局文件，那么应该命名为activity_sign_in.xml。建议采用以下基本命名规则：

值得一提的是，一些布局文件需要通过Adapter填充，如ListView，Recyclerview等列表视图，这种场景下，布局的命名应该以item_作为前缀。另外还有一种比较常见的情况，一个布局文件作为另一个布局文件的一部分而存在，或者使用了include，merge等标签的布局，建议使用partial_、include_或者merge_作为前缀，这一类布局的命名同样应该清晰的表达其意图。

• Id命名方式：

控件Id的命名应该以该控件类型的缩写作为前缀，同样要使用小写字母_下划线的组合形式，能够清晰表达意图是命名的前提：

示例如下：

<ImageView
    android:id="@+id/iv_profile"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content" />

<menu>
    <item
        android:id="@+id/menu_done"
        android:title="Done" />
</menu>

Color相关

colors.xml可以比喻成“调色板”，只映射ARGB值，不应该存在其他类型的数值，更不要使用它为不同的按钮来定义ARGB。

应该根据颜色或者风格对ARGB赋值，要使用基色_ARGB的命名规则：

<resources>
    <color name="white_FFFFFF">#FFFFFF</color>
    <color name="gray_DBDBDB">#DBDBDB</color>
    <color name="gray_939393">#939393</color>
    <color name="gray_5F5F5F">#5F5F5F</color>
    <color name="black_323232">#323232</color>
    <color name="green_27D34D">#27D34D</color>
</resources>

值得一提的是，这样规范的颜色很容易修改或重构，App所使用的颜色数量和种类也会变得非常清晰。

相反地，不使用以下对色值的命名规则：

<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，而且当改变基本色时，会造成毫无意义的重复操作。

Dimen相关

我们应该像对待colors.xml一样对待dimens.xml文件，与定义“调色板”无异，同样应该为字体定义一块“字号版”。

要使用以dimen_作为前缀的命名规范：

<resources>
    <!--SP-->
    <dimen name="dimen_22sp">22sp</dimen>
    <dimen name="dimen_18sp">18sp</dimen>
    <dimen name="dimen_15sp">15sp</dimen>
    <!--DP-->
    <dimen name="dimen_60dp">60dp</dimen>
    <dimen name="dimen_40dp">40dp</dimen>
    <dimen name="dimen_32dp">32dp</dimen>
</resources>

这样写的好处是，使组织结构和修改布局风格变得非常容易，同时也避免了对重复数值的定义。

String相关

对string的声明必须添加业务区分标识，前缀应该能清楚地表达功能职责，如，registration_email_hint，registration_name_hint。如果一个Sting不属于任何模块，就意味着它是通用的，遵循以下规范：

Style与Theme相关

Style与Theme的命名统一使用驼峰命名法。请谨慎使用style与theme，避免重复冗余的文件出现。可以出现多个styles.xml 文件，如：styles.xml，style_home.xml，style_item_details.xml，styles_forms.xml等。

另外值得一提的是：res/values目录下的文件可以任意命名，但前提是该文件能够明确表达职责所属，因为起作用的并不是文件本身，而是内部的标签属性。

编码规范与指导方针

XML文件规范

属性排序

对于如何排版一个布局文件，建议编码规范如下：

• 每个属性独占一行，缩进四个空格
• android:id作为第一个属性存在
• 如果存在style属性，则紧随id之后
• 如果不存在style属性，则android:layout_****紧随id之后
• 当布局中的一个元素不再包含子元素时，另起一行，使用自闭合标签/>，方便调整和添加新的属性

xml示例如下：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    >
    <TextView
        android:id="@+id/name"
        style="@style/FancyText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_alignParentRight="true"
        android:text="@string/name"
        />
    <include layout="@layout/reusable_part" />
</LinearLayout>

使用tools标签预览视图

• 布局预览建议使用tools:****相关属性，避免android:text="Hard code"等硬编码的出现，具体可参考Designtime attributes。

要使用如下示例方式设置属性：

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    tools:text="Home Link" />

不要使用以下硬编码方式：

<TextView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Home Link" />

通用style

参数校验

另外，在上面提到的准则中，有以下几点需要注意：

• android:id明显应该在layout文件中
• Layout文件中的android:orientation属性对于一个LinearLayout布局来说，更具有意义
• 由于使用android:text定义内容，所以这个属性应该放在Layout文件中
• 有时候将android:layout_width和android:layout_height属性放到一个style.xml中作为一个通用的风格更有意义，但是默认情况下把这些属性放到Layout文件中比放到style.xml文件中更加直观。
• 只有通用组件使用style，其他组件不必使用。

避免层级冗余的嵌套

Layout结构优化方面，应尽量避免深层次的布局嵌套，这不仅会引发性能瓶颈，还会带来项目维护上的麻烦。在书写布局之前应该对ViewTree充分的分析，善用<merge>标签减少层级嵌套，或者使用Hierarchy Viewer等UI优化工具对Layout进行分析与优化。可参考Optimizing Your UI与Optimizing Layout Hierarchies。

Java代码规范

代码注释

创建class文件时，文件头部必须添加作者的全称拼音，创建时间以及对本类的描述。创建方法函数时，被public声明的函数，必须添加注释，除getXXXX()和setXXXX()等简单函数外，可不必在方法头中添加注释，但需要对所操作的字段添加描述，这里提供一个注释样板，可供参考：

/**
 * 创建时间：2016/7/18 15:46 <br>
 * 作者： dengwei <br>
 * 描述： HTTP响应结果，状态码在[200..300)区间之外的异常信息包装类<br>
 */
public final class HttpException extends Exception {
 //HTTP状态码
  private final int code;
  //HTTP状态行信息
  private final String message;
  //HTTP完成响应
  private final transient Response<?> response;
  public HttpException(Response<?> response) {
    super("HTTP " + response.code() + " " + response.message());
    this.code = response.code();
    this.message = response.message();
    this.response = response;
  }
  /**
   * 获取HTTP响应异常时的状态码，状态码的值在[200..300)区间外
   *
   * @return HTTP响应状态码
   */
  public int code() {
    return code;
  }
  /**
   * 获取HTTP响应异常时的状态行信息，如果状态信息未知，返回值可能等与null。
   *
   * @return HTTP响应状态行信息
   */
  public String message() {
    return message;
  }
  /**
   * 获取完整的HTTP响应，可以从这里获取更多的响应信息。如果该异常已经被序列化了，返回值可能等于null。
   * @return 完整的HTTP响应
   */
  public Response<?> response() {
    return response;
  }
}

参数校验

绝大多数方法和构造器对于传递给它们的参数值都会有某些限制。例如，索引值必须是非负数，对象引用不能为null，等等这些都是很常见的。我们应该尽可能的在文档中清晰指明所有这些限制，并且在方法体的开头处检查参数，以强制施加这些限制。这是“应该在发生错误之后尽快检测出错误”这一普遍原则的一个具体情形。如果不能做到这一点，检测错误的可能性就比较小，即使检测到错误了，也比较难以确定错误的根源。

如：

构造函数和方法函数的有效性校验:

public class Foo {
  private int age;
  private String name;
  public Foo(int age) {
    if (age < 0) throw new IllegalArgumentException("age < 0: " + age);
    this.age = age;
  }
  public void setName(String name) {
    if (name == null) throw new IllegalArgumentException("name = null");
    this.name = name;
  }
}

Builder构造器有效性校验:

public class Foo {
  private int age;
  private String name;
  private Foo(int age, String name) {
    this.age = age;
    this.name = name;
  }
  public static class Builder {
    private int age;
    private String name;
    public Builder age(int age) {
      if (age < 0) throw new IllegalArgumentException("age < 0: " + age);
      this.age = age;
      return this;
    }
    public Builder setName(String name) {
      if (name == null) throw new IllegalArgumentException("name = null");
      this.name = name;
      return this;
    }
    public Foo build() {
      return new Foo(age, name);
    }
  }
}

在有些情况下，有效性检查工作非常的昂贵，或者根本是不切实际的，而且有效性检查已经隐含在计算过程中完成。例如，考虑对一个列表进行排序的方法:Collections.sort(List)要求列表中的所有对象都必须是可以相互比较的。在为列表排序的过程中，列表中的每个对象将与其他某个对象进行比较。如果这些对象不能相互比较，就会抛出ClassCastException，这正是sort()方法所应该做的。因此提前对列表中的所有元素进行有效性校验，显然没有多大意义。

另外值得一提的是，某些计算会隐式的执行必要的有效性校验，但是如果检查不成功就会抛出错误异常。换句话说，由于无效的参数值而导致计算过程抛出的异常，与文档中标明这个方法将抛出的异常并不相符。在这种情况下，就应该使用异常转译技巧，将计算过程中抛出的异常转换为正确的异常。我们拿上面的sort()方法的包装函数做举例说明:

public static class Utils {
  public static void sortByAge(List<Foo> fooList) {
    try {
      Collections.sort(fooList);
    } catch (ClassCastException e) {
      throw new IllegalArgumentException("element in fooList must implements \"Comparable\"!");
    }
  }
}

在设计方法的时候，不要认为对参数的任何限制都是件好事。相反，我们应该使它们尽可能的通用，并符合实际需要。假如方法对于它能接受的所有参数值都正常的完成工作，这时对参数的限制就应该越少越好。然后，通常情况下，有些限制对于
被实现的抽象来说是固有的。

总结，每当编写方法或者构造器的时候，就应该考虑它的参数有哪些限制。应该把这些限制尽可能的写进文档里，并在方法的开头处，通过显式的检查来实施这些有效性的校验，只要有一次校验失败，那些你为参数有效性校验所付出的努力，就得到了丰厚的回报。

处理Exception

如果对异常没有任何处理方案，至少应该在catch代码块中添加打印异常逻辑e.printStackTrace()，不建议采用的处理方式：

void setServerPort(String value) {
    try {
        serverPort = Integer.parseInt(value);
    } catch (NumberFormatException e) { }
}

你可能认为这种异常的触发概率极低，或者认为即便发生，也不需要做着重的处理，因此在catch()代码块中不添加任何逻辑，这大大增加了定位异常的难度，这里的建议是尽量处理每一个异常，具体的处理逻辑依赖于所处的上下文场景，对异常的处理同样能够增加系统的弹性，让程序变更健壮。

同时，遇到异常应该列出所有最小集合，不建议使用类似genericHandler()的通用异常捕获逻辑：

try {
    potentialIOExceptionFun();        // may throw IOException
    potentialParsingExceptionFun();   // may throw ParsingException
    potentialSecurityExceptionFun();  // may throw SecurityException
    // phew, made it all the way
} catch (Exception e) {                 // I'll just catch all exceptions
    genericHandler();                   // with one generic handler!
}

应该在catch语句中对异常分别处理，或者调用日志上传、异常统计等API。

Field定义与命名规范

对Field的定义应该放在文件的首位，并且遵守以下规范：

• 非静态变量，以m作为前缀
• 静态变量，以s作为前缀
• 静态常量命名字母全部大写，单词之间用下划线分隔

示例：

public class MyClass {
    public static final int SOME_CONSTANT = 42;
    public int publicField;
    private static MyClass sSingleton;
    int mPackagePrivate;
    private int mPrivate;
    protected int mProtected;
}

名词缩写规范

注解使用规范

• @Override： 子类实现或者重写父类方法时，必须使用@Override对函数进行标注。
• @SuppressWarnings： 注解@SuppressWarnings应该用在消除那些明确不可能发生的警告上，示例如下：

//泛型擦除
@SuppressWarnings("unchecked")
public static <R> FeedbackUseCase<R> createdUseCase() {
    return (FeedbackUseCase<R>) new FeedbackUseCase();
}
//请先确保能够非常正确地使用Handler
@SuppressWarnings("handlerLeak")
private Handler mHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        super.handleMessage(msg);
    }
};

更多关于注解的使用技巧与规范请参考这里，或者使用android.support.annotation依赖包中的注解优化程序。

限制变量的作用域

定义变量时，应该保证变量所在域的最小化，这样做不仅能够增加代码的可读性和可维护性，还能有效减少出错的可能性。变量定义在尽可能小的域中，也是良好封装性的体现。

值得注意的是，变量应该在首次使用时被初始化，如果没有足够的条件来使用它，那么就应该延迟创建的时机，直到真正需要使用时再去进行初始化操作。

Log输出规范

使用Log类打印一些重要的信息对开发者而言是很重要的事情，切记不要使用Toast来做信息打印。

针对不同的信息使用对应的日志输出类型：

• Log.v(String tag, String msg) (verbose)
• Log.d(String tag, String msg) (debug)
• Log.i(String tag, String msg) (information)
• Log.w(String tag, String msg) (warning)
• Log.e(String tag, String msg) (error)

一般情况下，当前类名作为tag，并且使用static final修饰，当前类的首行，示例如下：

public class MyClass {
    private static final String TAG = MyClass.class.getSimpleName();
    public myMethod() {
        Log.e(TAG, "My error message");
    }
}

VERBOSE和DEBUG类型的Log不应该出现在Release版本中，INFORMATION、WARNING和ERROR类型的Log可以留下来，因为这些信息的输出能够帮助我们快速地定位问题所在，当然前提是，需要隐藏重要的信息输出，如，用户手机号，邮箱等。

只在Debug环境中输出日志的小技巧：

if (BuildConfig.DEBUG) Log.d(TAG, "The value of x is " + x);

类成员排序规范

关于这个并没有硬性要求，不过好的排序方式，能够提高可读性和易学性。这里给出一些排序建议：

1. 常量
2. 字段
3. 构造函数
4. 被重写的函数（不区分修饰符类型）
5. 被private修饰的函数
6. 被public修饰的函数
7. 被定义的内部类或者接口

示例如下：

public class MainActivity extends Activity {
    private static final String TAG = MainActivity.class.getSimpleName();
    private String mTitle;
    private TextView mTextViewTitle;
    @Override
    public void onCreate() {
        ...
    }
    private void setUpView() {
        ...
    }
    public void setTitle(String title) {
        mTitle = title;
    }
    static class AnInnerClass {
    }
}

如果继承了Android组件，比如Activity或者Fragment，重写生命周期函数时，建议按照组件的生命周期进行排序，如：

public class MainActivity extends Activity {
    @Override
    public void onCreate() {}
    @Override
    public void onResume() {}
    @Override
    public void onPause() {}
    @Override
    public void onDestroy() {}
}

方法函数中的参数排序规范

在Android日常开发中，很多情况下都需要使用Context，所以经常被作为参数传入方法中，这里给出的建议是，如果函数签名中存在Context，则作为第一个参数，如果存在Callback则作为最后一个参数，示例如下：

public void loadUserAsync(Context context, int userId, UserCallback callback);

字符串常量的命名与赋值规范

Android SDK中诸如SharedPreferences，Bundle和Intent等，都采用key-value的方式进行赋值，当使用这些组件时，key必须被static final所修饰，并且命名应该符合以下规范：

需要注意的是，当调用Fragment的.getArguments()方法时，返回值同样是一个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";

Activity和Fragment打开方式

当通过Intent或者Bundle向Activity与Fragment传值时，应该遵循上面提到的key-value规范，公开一个被public static修饰的方法，方法的参数应该包含所有打开这个Activity或者Fragment的信息，示例如下：

• 通过.startActivity()函数，开启指定Activity。

public static void startActivity(AppCompatActivity startingActivity, User user) {
    Intent intent = new Intent(startingActivity, ThisActivity.class);
    intent.putParcelableExtra(EXTRA_USER, user);
    startingActivity.startActivity(intent);
  }

• 通过.newInstance()函数，加载指定Fragment。

public static UserFragment newInstance(User user) {
    UserFragment fragment = new UserFragment;
    Bundle args = new Bundle();
    args.putParcelable(ARGUMENT_USER, user);
    fragment.setArguments(args)
    return fragment;
}

需要注意一下两点：

1. 以上这些方法应该放在类的开头，至少应该放在.onCreate()之前。
2. Intent中所涉及的key，如EXTRA_USER，ARGUMENT_USER等，如果与其他业务无关，应该放在本类中被private所修饰，不暴露给其它外部类。如果是通用key，则应该声明在公共Common文件中。

提高程序可读性

我们应该在日常开发中养成添加注释的习惯，避免魔鬼数字与硬编码的出现，这样不仅可以提高可读性与可维护性，还能为逻辑的重构带来很大的便捷。

这里有个很好的建议，使用RxJava让程序变得更加可读，更加函数化。

这里有一个示例，可供参考，“对一个数组中的每一个元素乘以2，然后筛选小于10的元素，并放入最终的集合中”

一般写法示例：

Integer[] integers = { 0, 1, 2, 3, 4, 5 };
Integer[] doubles = new Integer[integers.length];
for (int i = 0; i < integers.length; i++) {
    doubles[i] = integers[i] * 2;
}
List<Integer> results = new ArrayList<>(doubles.length);
for (Integer integer : doubles) {
    if (integer < 10) {
        results.add(integer);
    }
}

使用RxJava的流式调用示例，提高可读性：

//假设你了解这些操作符的工作原理
List<Integer> results = Observable.from(integers)
                                  .map(new Func1<Integer, Integer>() {
                                      @Override
                                      public Integer call(Integer integer) {
                                          return integer * 2;
                                      }
                                  })
                                  .filter(new Func1<Integer, Boolean>() {
                                      @Override
                                      public Boolean call(Integer integer) {
                                          return integer < 10;
                                      }
                                  })
                                  .toList()
                                  .toBlocking()
                                  .first();

另外需要补充的一点是：当使用Builder或者其他链式结构创建对象时，每一个方法的调用都应另起一行，并且每一行都以.开头，示例如下：

Picasso.with(context)
        .load(R.drawable.placeholder)
        .into(imageView);

Git分支管理与提交规范

多人协作开发情况下，每个人都应该了解并理解Git分支模型

这里意见几篇质量极高的文章以供参阅，因此不再赘述。

git版本控制开发流程小结笔记（一）

git版本控制开发流程小结笔记（二）

一个成功的 Git 分支模型

因为Git的操作指令非常灵活，所以这里只给出提交备注的建议：

1. 提交备注

• 如果使用类似$ git commit等语句，建议采用以下规范添加完整的提交备注

  标题与内容之间保持一个空行，示例如下：

      Fixed #<此bug在bug管理工具上的索引、路径或其他标识>
  
      内容部分添加简短描述，如改动原因，主要变动或者一些重要的建议事项。最后如果有需要可以添加对应的网址，如bug地址等。
  

• 如果使用$ git commit -m""等语句，建议采用以下规范添加简短的提交备注

  如果真的没有什么详细内容可以描述，使用简短的提交备注形式，是一种不错的选择，示例如下：

  git commit -m 'Fixed #[issue number]: [Short summary of the change].'
  

下面是几个常用提交动词，以供参考：

• Added : ( 新加入的需求 )
• Fixed : ( 修复Bug，建议后面加上Bug索引或路径，如：Fixed #[issue number] )
• Updated : ( 完成的任务，重构代码，或者由于第三方模块变化而做的变化）

2. 标题尽量不超过50个字符

3. 标题的首字母大写（如果你习惯使用一个英文标题的话）

使用这种标题：

    Accelerate to 88 miles per hour

而不是：

    accelerate to 88 miles per hour

4. 标题不以“句号”作为结尾

使用这种标题：

    Open the pod bay doors

而不是：

    Open the pod bay doors.

5. 内容描述尽量不要超过72个字符

6. 在内容中对此次提交的“Why”以及“How”来进行描述

最后，我们一起来看一看，一个优雅的提交备注是什么样子的：

   Simplify serialize.h's exception handling

   Remove the 'state' and 'exceptmask' from serialize.h's stream
   implementations, as well as related methods.

   As exceptmask always included 'failbit', and setstate was always
   called with bits = failbit, all it did was immediately raise an
   exception. Get rid of those variables, and replace the setstate
   with direct exception throwing (which also removes some dead
   code).

   As a result, good() is never reached after a failure (there are
   only 2 calls, one of which is in tests), and can just be replaced
   by !eof().

   fail(), clear(n) and exceptions() are just never called. Delete
   them.