以下代码样式都是应严格遵守的规则（而非指南或建议）。如果所贡献的 Android 代码没有遵守以下规则，我们通常不会接受此类代码。我们知道，并非所有的现有代码都遵守了这些规则，但我们希望所有新代码都能遵守这些规则。

Java 语言规则

Android 遵循标准 Java 编码规范以及下文所述的其他规则。

请勿忽略异常

开发者可能会倾向于编写完全忽略异常的代码，例如：

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

千万不要这样做。虽然您可能认为自己的代码永远不会遇到这种错误，或者无需费心处理这种错误，但像上例那样忽略异常会在您的代码中埋下隐患，这种错误总有一天会被他人触发。您必须有原则地处理代码中的每个异常；具体处理方式因情况而异。

无论何时，只要遇到空的 catch 子句，就应该保持警惕。当然，在某些时候，空的 catch 语句确实没什么问题，但至少你得想一想。在 Java 中，你怎么小心都不为过。-James Gosling

可接受的替代方案（按优先顺序排列）包括：

请勿捕获常规异常

在捕获异常时，开发者可能会为了偷懒而倾向于采用以下处理方式：

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

千万不要这样做。几乎所有情况下都不适合捕获常规异常或 Throwable（最好不要捕获 Throwable，因为它包含 Error 异常）。这样做非常危险，因为这意味着系统会在处理应用级错误期间捕获到您从未预料到的异常（包括 ClassCastException 之类的 RuntimeException）。它掩盖了代码的故障处理属性，也就是说，如果有人在您所调用的代码中添加了一种新类型的异常，编译器不会帮助您意识到您需要采取不同的方式来处理该错误。在大多数情况下，您不应以相同的方式处理不同类型的异常。

这条规则的特例是：在测试代码和顶级代码中，您希望捕获所有类型的错误（以防它们显示在界面中或者以便一直进行批处理作业）。在这些情况下，您可以捕获常规异常（或 Throwable）并适当地处理错误。但在这样做之前，请务必三思，然后添加备注以说明为何在此处执行这类操作是安全之举。

捕获常规异常的替代方案：

请谨记：异常是您的朋友！当编译器抱怨您没有捕获异常时，别闷闷不乐！您应该微笑：因为编译器让您能够更加轻松地捕获代码中的运行时错误。

请勿使用终结器

终结器可以在对象被垃圾回收器回收时执行一段代码。虽然终结器非常便于进行资源清理（尤其是外部资源），但并不能保证终结器何时被调用（甚至根本不会被调用）。

Android 不使用终结器。在大多数情况下，您可以通过良好的异常处理流程实现终结器功能。如果您的确需要终结器，请定义一个 close() 方法（或类似方法），并注明需要调用该方法的确切时间（有关示例，请参阅 InputStream）。这种情况下，可以（但并非必须）在终结器中输出简短的日志消息，前提是不会输出大量日志消息。

完全合格的导入

当您想要使用 foo 包中的 Bar 类时，可以使用以下两种方式导入：

使用 import foo.Bar; 导入所有 Android 代码。在 Java 标准库（java.util.*、java.io.* 等）和单元测试代码 (junit.framework.*) 中创建显式异常。

Java 库规则

使用 Android 的 Java 库和工具需要遵守相关规范。在某些情况下，具体规范发生了一些重大变化，旧代码可能使用的是已弃用的模式或库。使用此类代码时，可以继续遵循现有样式。不过，在创建新组件时，请不要再使用已弃用的库。

Java 样式规则

使用 Javadoc 标准备注

每个文件都应该在顶部放置版权声明，其后是 package 和 import 语句（各个块之间用空行分隔），最后是类或接口声明。在 Javadoc 备注中说明类或接口的作用。

/*
 * Copyright (C) 2015 The Android Open Source Project
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package com.android.internal.foo;

import android.os.Blah;
import android.view.Yada;

import java.sql.ResultSet;
import java.sql.SQLException;

/**
 * Does X and Y and provides an abstraction for Z.
 */

public class Foo {
    ...
}

您编写的每个类和重要的公开方法都必须包含 Javadoc 备注，至少用一句话说明类或方法的用途。句式应以第三人称描述性动词开头。

示例：

/** Returns the correctly rounded positive square root of a double value. */
static double sqrt(double a) {
    ...
}

或

/**
 * Constructs a new String by converting the specified array of
 * bytes using the platform's default character encoding.
 */
public String(byte[] bytes) {
    ...
}

对于普通的 get 和 set 方法（如 setFoo()），您无需编写 Javadoc，要写也不过是“设置 Foo”。如果该方法执行更复杂的操作（例如强制实施约束条件或具有重大副作用），那么您必须添加备注。如果属性“Foo”的意思不明确，您也应该添加备注。

您所编写的每一种方法（无论是公开方法还是其他方法）都将受益于 Javadoc。公开方法是 API 的一部分，因此需要 Javadoc。Android 目前并不强制要求采用特定样式来编写 Javadoc 备注，但建议您参照如何为 Javadoc 工具编写文档备注中的说明。

编写简短方法

在可行的情况下，尽量编写短小精炼的方法。我们了解，有些情况下较长的方法是恰当的，因此对方法的代码长度没有做出硬性限制。如果某个方法的代码超出 40 行，请考虑是否可以在不破坏程序结构的前提下对其拆解。

在标准位置定义字段

在文件的顶部或者在使用它们的方法之前定义字段。

限制变量的作用域

尽可能缩小局部变量的作用域。这样做有助于提高代码的可读性和可维护性，并降低出错的可能性。每个变量应该在包含变量所有使用场合的最内层的块中进行声明。

局部变量应该在首次使用时声明。几乎每个局部变量声明都应该包含一个初始化程序。如果您还没有足够的信息来合理地初始化某个变量，请推迟到信息充足时再进行声明。

try-catch 语句是例外情况。如果通过一个会抛出受检异常的方法的返回值来初始化变量，则必须在 try 块中进行初始化。如果该值必须在 try 块之外使用，那么您必须在 try 块之前对其进行声明，因为它在 try 块中尚无法合理地初始化：

// Instantiate class cl, which represents some sort of Set
Set s = null;
try {
    s = (Set) cl.newInstance();
} catch(IllegalAccessException e) {
    throw new IllegalArgumentException(cl + " not accessible");
} catch(InstantiationException e) {
    throw new IllegalArgumentException(cl + " not instantiable");
}

// Exercise the set
s.addAll(Arrays.asList(args));

不过，即使是这种情况，也可以通过将 try-catch 块封装在某个方法中来避免：

Set createSet(Class cl) {
    // Instantiate class cl, which represents some sort of Set
    try {
        return (Set) cl.newInstance();
    } catch(IllegalAccessException e) {
        throw new IllegalArgumentException(cl + " not accessible");
    } catch(InstantiationException e) {
        throw new IllegalArgumentException(cl + " not instantiable");
    }
}

...

// Exercise the set
Set s = createSet(cl);
s.addAll(Arrays.asList(args));

循环变量应该在 for 语句本身中进行声明，除非有令人信服的理由不这么做：

for (int i = 0; i < n; i++) {
    doSomething(i);
}

和

for (Iterator i = c.iterator(); i.hasNext(); ) {
    doSomethingElse(i.next());
}

为 import 语句排序

import 语句的顺序为：

  1. 导入 Android 包

  2. 导入第三方包（com、junit、net、org）

  3. java 和 javax

要完全符合 IDE 设置，导入顺序应为：

最初对于语句顺序并没有样式要求，这意味着 IDE 经常会改变顺序，或者 IDE 开发者必须停用自动导入管理功能并手动维护导入语句。这样相当不方便。当提及 Java 样式时，开发者们喜欢的样式五花八门，最终针对 Android 简单归结为“选择一种兼容一致的排序方式”。因此我们选择了一种样式，更新了样式指南，并让 IDE 遵循该指南。我们希望 IDE 用户在编写代码时，系统对所有软件包的导入都符合此模式，无需再进行额外的工程处理。

这种样式是按以下原则选取的：

静态导入的使用和位置一直都存在争议。有些人希望静态导入穿插在其他导入语句之间，而有些人更希望其位于其他所有导入语句的上方或下方。此外，我们还没有确定如何让所有 IDE 都使用同一种顺序。由于许多人认为这个问题不太重要，因此您只需在保持一致的前提下自行决定即可。

使用空格缩进

我们使用四 (4) 个空格来缩进块，而不要使用制表符。如果您有疑问，请与周围的代码保持一致。

我们使用八 (8) 个空格来缩进自动换行，包括函数调用和赋值。正确示例如下：

Instrument i =
        someLongExpression(that, wouldNotFit, on, one, line);

错误示例如下：

Instrument i =
    someLongExpression(that, wouldNotFit, on, one, line);

遵循字段命名规范

例如：

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;
}

使用标准大括号样式

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

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

我们需要在条件语句周围添加大括号。例外情况：如果整个条件语句（条件和主体）适合放在同一行，那么您可以（但不是必须）将其全部放在一行上。例如，我们接受以下样式：

if (condition) {
    body();
}

同样也接受以下样式：

if (condition) body();

但不接受以下样式：

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

限制代码行长度

您的代码中每一行文本的长度都应该不超过 100 个字符。虽然关于此规则存在很多争论，但最终决定仍是以 100 个字符为上限，不过存在以下例外情况：

使用标准 Java 注释

注释应该位于同一语言元素的其他修饰符之前。简单的标记注释（例如 @Override）可以与语言元素列在同一行。如果有多个注释或参数化注释，则应各占一行并按字母顺序排列。

Java 中 3 个预定义注释的 Android 标准做法如下：

将首字母缩写词视为字词

在为变量、方法和类命名时，请将首字母缩写词和缩写形式视为字词，使名称更具可读性：

良好 不佳
XmlHttpRequest XMLHTTPRequest
getCustomerId getCustomerID
class Html class HTML
String url String URL
long id long ID

由于 JDK 和 Android 代码库在首字母缩写词上非常不一致，几乎也不可能与周围的代码保持一致。因此，请务必将首字母缩写词视为字词。

使用 TODO 备注

为代码使用 TODO 备注是短期的临时解决方案，或者说足够好但并不完美。TODO 备注应该以全部大写的字符串 TODO 开头，后跟一个冒号：

// TODO: Remove this code after the UrlTable2 has been checked in.

和

// TODO: Change this to use a flag instead of a constant.

如果您的 TODO 采用“在未来的某个日期做某事”的形式，请确保在其中包含一个非常具体的日期（“在 2005 年 11 月前修复”）或者一个非常具体的事件（“在所有生产环境合成器都可处理 V7 协议后移除此代码”）。

谨慎使用日志记录

虽然日志记录非常有必要，但对性能却有明显的负面影响，如果不能保持一定程度的简洁性，就会迅速失去其实用性。日志记录工具提供以下 5 种不同级别的日志记录：

注意事项：

保持一致

总而言之：保持一致。如果您正在修改代码，请花几分钟时间看一下周围的代码并确定其样式。如果该代码在 if 语句周围使用空格，那么您也应该这样做。如果代码备注的周围是用星号组成的小方框，您也应该将备注放在这样的小方框内。

制定样式规范的目的是整理出通用的编码词汇表，以便人们可以专注于您所说的内容，而不是您表达的方式。我们在此提出整体样式规则，让用户都知道这一词汇表，但局部样式也很重要。如果您添加到文件的代码看起来与其周围的现有代码明显不同，那么当读者读到此处时，这些代码会打乱他们的节奏。请尽量避免这种情况。

Javatests 样式规则

请遵循测试方法的命名规范，并使用下划线将被测试的内容与被测试的具体情况区分开来。这种样式可让您更容易看出正在测试的情况。例如：

testMethod_specificCase1 testMethod_specificCase2

void testIsDistinguishable_protanopia() {
    ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
    assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
    assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
}