代码格式化：团队协作的基石

代码风格不统一，是团队矛盾的导火索。

review 代码时，你会发现这种代码在一个团队里会出现：

public class UserService{private String name;public String getName(){return name;}public void setName(String name){this.name=name;}}

三个人写出了三种格式，这不是个性，这是灾难。

所以我们要聊格式化。

缩进与空格

缩进用 4 个空格，Tab 在不同编辑器里宽度不一致，会导致代码在别人那里乱掉。

规范	正确	错误
大括号	{ 不换行，与 PHP/GO 保持一致	换行
空格	if (x > 0)	if(x>0)
运算符	a + b	a+b
逗号后	a, b, c	a,b,c
分号后	不加空格	—

IDE 的格式化快捷键就能解决 90% 的问题：

操作系统	快捷键
Windows/Linux	Ctrl + Alt + L
macOS	Cmd + Option + L

行列长度

单行不超过 120 字符，超长就拆。别让代码横向滚出视野。

// ❌ 超长行，横向滚到你崩溃
public String buildUserInfoString(String firstName, String lastName, String email, String phone, String address) { ... }

// ✅ 拆成多行，参数对齐
public String buildUserInfoString(
    String firstName,
    String lastName,
    String email,
    String phone,
    String address
) { ... }

// ✅ 或者用 Builder 模式
UserInfo info = UserInfo.builder()
    .firstName(firstName)
    .lastName(lastName)
    .email(email)
    .phone(phone)
    .address(address)
    .build();

格式化前后对比

// ❌ 格式化前
public class UserService{private String name;public String getName(){return name;}public void setName(String name){this.name=name;}}

// ✅ 格式化后
public class UserService {
    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

配置 .editorconfig

把格式化规则写进 .editorconfig，让团队所有人共享同一套标准：

root = true

[*.java]
indent_style = space
indent_size = 4
max_line_length = 120
trim_trailing_whitespace = true
insert_final_newline = true

Git Hook 可以强制提交前格式化，防止脏代码入库。

Maven 集成

Google Java Format

# 单次格式化
mvn google-java-format:format

# 格式化并覆盖原文件
mvn google-java-format:format -Dgjf.skipSortImports=false

Checkstyle

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-checkstyle-plugin</artifactId>
    <configuration>
        <configLocation>checkstyle.xml</configLocation>
    </configuration>
</plugin>

最佳实践

1. IDE 格式化快捷键练成本能。每次写完代码顺手按一下，不费事。
2. 把 .editorconfig 提交到仓库。新人 clone 下来就能用团队标准。
3. CI 里跑 checkstyle。格式不统一的代码不让 merge。
4. 不要在 review 里争论格式。格式问题让工具判断，人应该花在代码逻辑上。

格式化是团队的契约，用工具来执行，不要用嘴。