这份规范最初由 Google 内部使用，后来公开发布，并成为许多公司项目（如 Android 开发）和开源项目的基石。

下面我将为你详细解读这份规范的核心内容,并附上官方链接。

核心原则

在深入具体规则之前,理解其背后的核心原则至关重要：

1. 可读性优先：代码被阅读的次数远多于被编写的次数，代码的首要目标是让其他开发者（包括未来的你）能够轻松理解。
2. 一致性至上：在一个项目中，保持代码风格的一致性可以减少认知负荷，即使某个规则并非“最佳”，但统一执行比混乱要好。
3. “明胜于晦” (Clarity over Cleverness)：代码应该清晰直白，避免使用过于复杂、晦涩的技巧，即使这会牺牲一些“简洁性”。
4. 防御性编程：要考虑到代码可能被错误使用的情况，通过良好的设计（如不可变对象、参数校验）来增强代码的健壮性。

详解

Google Java 规范主要包含以下几个部分：

源文件基础

• 文件名：文件名必须与公共类名完全一致，并以 .java
  • public class MyClass 必须存放在 MyClass.java 文件中。
• 文件编码：源文件必须使用 UTF-8 编码。
• 特殊字符：
  • 空格字符：只使用 ASCII 空格字符（0x20），不要使用 Tab 制表符，编辑器应设置为将 Tab 自动替换为 4 个空格。
  • 特殊转义序列：对于 \b, \t, \n, \f, \r, \", \', \\，使用它们的转义形式，对于其他非打印字符，使用 Unicode 转义序列，\u0001。

代码格式

这是最直观的部分,主要定义了代码的“外观”。

• 大括号：

  • K&R 风格：左大括号 不换行，与它所属的语句在同一行。

    if (condition) {
    // do something
    }

  • 例外：枚举类、匿名类，左大括号可以换行，以提高可读性。

    public enum Answer {
    YES,
    NO,
    MAYBE
    }

• 缩进：

  • 使用 4 个空格 进行一级缩进，不要使用 Tab。
  • 连续的代码块（如 if-else、for、while）必须缩进。

• 行长度：

  • 软限制为 100 个字符，尽量让代码行在 100 字符以内。
  • 硬限制为 120 个字符，任何情况下都不能超过 120 字符。
  • 如果一行超过 100 字符，必须进行换行，换行的基本原则是：
    • 在逗号 后换行。
    • 在操作符 前换行（而不是后）。
    • 对齐原则：换行后的代码应该与上一行中位于高一层次的语法元素对齐。

  // 好的换行示例
  String name = String.format("%s %s, %s",
                             firstName, lastName, middleInitial);
  // 另一种常见的换行方式（对齐到操作符开始处）
  String query = "SELECT id, name, address " +
                 "FROM users " +
                 "WHERE status = 'active'";

• 垂直空白：

  
  （图片来源网络，侵删）
  • 使用空行来分隔逻辑相关的代码块,提高可读性。
  • 类内不同方法之间、方法内的逻辑段落之间。

• 水平空白：

  • 关键字 (if, for, catch) 和左括号 之间需要一个空格。
  • 方法名/构造器名 和 左括号 之间不需要空格。
  • 逗号 和后一个参数 之间需要一个空格。
  • 二元操作符 (, , >) 前后都需要一个空格。

命名约定

清晰的命名是代码可读性的基石。

特别说明：

• 缩写：除非是众所周知的缩写（如 URL, HTTP），否则应避免使用。HTMLParser 优于 HtmlParser。
• 可读性：优先保证可读性。horizontalScreenResolution 比 hScreenRes 更好。

编程实践

这是规范的核心,关乎代码的质量和设计。

• @Override 注解：

  • 只要方法重写了父类的方法,就必须使用 @Override 注解。
  • 对于实现接口的方法,也推荐使用，这可以防止拼写错误导致的意外“新方法”。

• 异常处理：

  • 禁止使用 catch (Exception e) 或 catch (Throwable t)，除非你明确知道如何处理所有可能的异常。
  • 优先捕获具体的异常类型。
  • 不要吞掉异常：不要只捕获异常却不做任何处理（如 catch (Exception e) {}），至少要打印日志或重新抛出。
  • 不要使用异常来控制流程：异常是用于处理“异常”情况的，不要用它来代替 if-else 判断。

• 静态成员：

  • 优先使用静态导入：对于 Math 或 Guava 等工具类中的静态方法，使用静态导入可以简化代码。

    import static java.lang.Math.PI;
    import static java.util.Collections.emptyList;

  // 代码中可以直接使用 double circumference = radius 2 PI; List empty = emptyList();

• Finalizers (finalize 方法)：

  • 避免使用。finalize 方法执行时间不可预测，且可能导致性能问题和不可靠的行为，使用 try-finally 块或 try-with-resources 来管理资源是更好的选择。

Javadoc 注释

Javadoc 是文档和代码的桥梁，必须遵循规范。

• 块注释格式：。
• 类/接口：描述其用途、职责，使用第一人称。
• 方法：
  • @param：描述每个参数的含义，而不是它的类型。
  • @return：描述返回值的含义。
  • @throws：描述该方法可能抛出的特定异常及其触发条件。
• 第一人称：使用 "This..." 而不是 "The..."。
• 代码片段：在 Javadoc 中使用 {@code ...} 来标记代码片段，这样可以保留格式，避免被 HTML 解析。

  /**
   * Returns the character at the specified index. An index ranges from {@code 0}
   * to {@code length() - 1}.
   *
   * @param index the index of the character to return
   * @return the specified character
   * @throws StringIndexOutOfBoundsException if the {@code index} is negative or
   *         greater than or equal to {@code length()}
   */
  public char charAt(int index) {
      // ...
  }

如何应用和检查

1. 官方文档：

   • Google Java Style Guide (英文): https://google.github.io/styleguide/javaguide.html
   • Google Java Style Guide (中文翻译): https://github.com/google/styleguide/blob/gh-pages/javaguide/README.md (这是一个非官方但流传很广的翻译，请注意时效性)

2. 自动化工具： 为了确保团队代码风格的一致性，强烈建议使用自动化工具。

   • Google Java Format：

     • 一个由 Google 官方提供的代码格式化工具，可以自动处理缩进、大括号位置、行长度等格式问题。
     • 可以作为 Maven/Gradle 插件集成到构建流程中。

   • Checkstyle：

     • 一个强大的静态代码分析工具,可以检查代码是否符合预定义的规则集。
     • Google 提供了基于其规范的 Checkstyle 配置文件，可以直接使用。
     • 可以集成到 IDE 和 CI/CD 流程中，在提交代码或合并请求时自动检查。

   • Error Prone：

     • 一个基于 Java Compiler Tree API 的静态代码分析工具，可以发现更多潜在的 Bug 和代码坏味道。
     • Google 内部项目广泛使用。

   • PMD：

     另一个流行的静态代码分析工具,功能与 Checkstyle 类似。

   • IntelliJ IDEA / Eclipse：

     这两款主流 IDE 都内置了对 Google Java Style 的支持，你可以在代码风格设置中选择 "Google Style"，并配置自动格式化。

遵循 Google Java 编码规范，不仅仅是写代码时注意空格和括号，更是一种工程思维的体现，它通过一套统一的、经过验证的最佳实践，帮助开发者：

• 写出更健壮、更少 Bug 的代码。
• 让团队协作更顺畅，减少因风格不一致带来的沟通成本。
• 提升代码的可维护性，让项目在长期发展中保持健康。

对于任何严肃的 Java 采纳并严格执行这套规范都是一个非常好的起点。