为什么需要代码格式化规范
刚进新公司那会儿，我接手了一个老项目。打开文件的一瞬间，差点没认出来这是 JavaScript —— 有的缩进用空格，有的用 Tab；括号有时换行，有时顶格写；变量命名一会儿是驼峰，一会儿又下划线。读一段代码像在解谜。
后来才知道，这不是代码功能的问题，而是缺少统一的格式化规范。这种混乱不仅影响阅读，还容易在合并代码时引发无意义的冲突。
格式不统一带来的真实问题
上周同事提交了一次“看似改动很大”的 PR，点开一看，其实逻辑只改了几行，但因为全篇重新格式化了缩进和空行，导致 Git 显示上百处变更。审查的人根本没法专注看真正的修改点。
这就是没有格式化规范的代价：浪费时间、增加沟通成本、降低协作效率。
常见的格式化规则要素
一个实用的代码格式化规范不是写在文档里就完事了，它得能落地。以下是大多数团队都会关注的核心项：
缩进与空格
统一使用 2 个空格还是 4 个？Tab 还是空格？建议选空格，避免不同编辑器显示错位。比如在 JavaScript 中：
function calculateTotal(items) {<br> let total = 0;<br> for (let i = 0; i < items.length; i++) {<br> total += items[i].price;<br> }<br> return total;<br>}分号与引号
JavaScript 社区对是否加分号一直有争议。关键是——团队内部要一致。如果用了 ESLint 或 Prettier，就让它自动处理。比如统一使用单引号、末尾加分号：
const name = 'xiaoming';<br>const isActive = true;命名风格
变量用 camelCase，常量用 UPPER_CASE，类名用 PascalCase。别在一个文件里看到 getUserName、fetch_user_info、QUERY_TIMEOUT 同时存在。
用工具代替人工检查
靠人提醒格式问题太累。现在主流做法是用工具自动化。
Prettier 几乎成了前端项目的标配。安装后加一行脚本：
npx prettier --write src/保存文件时自动格式化，VS Code 配合插件还能实时调整。
后端也一样。Java 用 Checkstyle，Python 用 Black 或 autopep8，Go 直接内置了 gofmt。这些工具跑一遍，代码立马整齐划一。
如何在团队中推行格式化规范
别一上来就扔一堆规则。先从最影响体验的问题入手，比如“禁止混合使用空格和 Tab”。
在项目根目录放 .prettierrc、.editorconfig，再配上 husky + lint-staged，在提交代码前自动格式化改动的文件：
{<br> "files": ["*.js", "*.ts"],<br> "tabWidth": 2,<br> "semi": true,<br> "singleQuote": true<br>}新人入职 clone 项目，装完依赖就能写出和大家风格一致的代码，这才是真正的平滑融入。
小改变带来大不同
去年我们给一个老旧 PHP 项目引入了 PHP_CodeSniffer，并定制了一套基础规则。花了一天时间批量修复历史格式问题，之后每次提交都自动检查。
三个月后回头看，代码文件虽然业务逻辑没变，但看起来清爽多了。连实习生都说：“这个项目看着不闹心。”
代码是写给人看的，其次才是机器。格式化规范不是约束，而是尊重——对你队友时间的尊重。