标识符命名规范八条铁律：从语法合法性到工程实践全解析

做了这么多年开发，代码里最让我受不了的并不是业务复杂度，而是一件特别基础的事：打开一个类文件，迎面看到的全是 a、b、data1、data2、temp15 这种命名。那种感觉，就像收到一份没有目录、没有注记的旧代码，每一个字符都认识，连在一起就是不知道在做什么。后来我才慢慢意识到，标识符的命名规范不是写完代码之后的锦上添花，它直接决定了这套代码未来是让人省心，还是让人崩溃。

这篇文章我想把自己的经验和踩过的坑完整梳理一遍。标题里的“8标识符”，说的其实是八条核心规范——我在几个团队里推过很多次，基本都能在两周内把代码库的可读性明显拉上来。内容覆盖了语言层面的合法性规则、不同语言的差异、方法命名规范、分支命名规范、框架（比如 Next.js）命名要求，还有像 ORA-00972: 标识符过长、未定义的标识符 true 这种真实报错的排查思路。无论你是刚入行的新手，还是已经在维护老项目的老兵，这套东西应该都能直接拿去用。

1. 标识符到底包括什么？先把边界搞清楚

很多朋友一听到“标识符命名规范”，第一反应就是“变量名怎么写”。其实标识符的范围比这大得多：变量名、函数名、类名、接口名、包名、模块名、文件名、数据库表名和字段名、Git 分支名、枚举值、注解名，甚至连代码仓库名也算。它们本质上都是同一个东西——用来唯一指代某个实体的名字。

所以你会发现，一个 Java 项目里，从最外层的包名 com.company.order，到中间层的类名 OrderService，再到方法名 createOrder，再到局部变量 orderId，再到 Git 分支名 feature/order-cancel、数据库表字段 order_status，它们其实是在同一条命名链路上。只要其中某一环命名混乱，整条链路的可读性都会崩掉。

这也是为什么我特别反对“命名规范只是编码风格”这种说法。编码风格管的是空格、缩进、分号，而命名规范管的是整个系统的可理解性。一段代码如果逻辑再正确，名字起得糊里糊涂，三个月后你自己回来都要靠猜，更别提团队协作了。所以在这篇文章里，我把所有“能起名字的地方”都统一纳入讨论，围绕同一套原则展开。

1.1 合法性和可读性：两种不同的规则

在聊命名规范之前，必须先分清两个容易混淆的层面：合法性规则和可读性规则。

合法性规则是编程语言强制的，不满足就一定报错。比如 Java 里标识符不能用数字开头，不能跟关键字重名，不能包含空格和除 $、_ 之外的符号。这是语法层面的底线，没有任何商量余地。

可读性规则是团队约定俗成的。比如 Java 里变量名用驼峰 userName，类名用大驼峰 UserService，常量用全大写 MAX_SIZE。这些约定不遵守不会报错，代码一样能跑，但会让团队协作变得艰难。

很多团队把这两层混在一起讨论，结果就是“语法允许”和“规范允许”经常被搞混。我见过有人拿“编译能通过”来反驳命名规范类的 code review 意见，这就是典型的把合法性规则当成了全部。正确的理解应该是：合法性是底线，可读性是标准。下面我会分开来讲。

2. 命名规范的第一道坎：合法性与语法边界

先从最硬的语法规则说起，因为这是所有命名的基础。以 Java 为例，标识符的规则其实非常明确：可以由字母、数字、美元符号 $ 和下划线 _ 组成，但不能以数字开头，不能是 Java 的保留关键字。

java复制// 合法的标识符示例
int userId;
double _price;
String $name;
OrderService orderService;

// 非法的标识符示例（会编译报错）
int 2userId;      // 不能以数字开头
String class;     // 关键字不能做标识符
String user-name; // 不能包含连字符
int user.id;      // 点号不能出现在标识符里

Java 的关键字列表是固定的，比如 class、interface、new、return、if、else、for、while、true、false 等。这里特别要注意的是 true、false、null 这三个字面量，它们虽然不是关键字，但也不能作为标识符使用。这就是我在后面第五部分要详细讲的 未定义的标识符 true 报错的根源之一。

不过在讲不同语言之前，有一个点很容易被忽略：Java 标识符的合法字符其实是基于 Unicode 的。这意味着中文变量名在 Java 里其实也能编译通过：

java复制String 用户名 = "张三";

但我在实际工作中强烈不建议这么干，原因很现实：团队的键盘输入习惯、IDE 的显示字体、代码 diff 工具的乱码处理、以及大部分开源工具的兼容性，都对非 ASCII 标识符支持不太好。名字是给人看的，也是给工具链用的，没必要在这种地方搞特立独行。

2.1 各语言差异速查

不同语言的标识符规则差异不小，我整理了一个常用的对照表，方便大家快速查阅：

这个表格里的信息，是我在日常中真正遇到过问题的位置。比如 SQL 的 30 字节限制，几乎每一个用 Oracle 的项目都会踩一次 ORA-00972: 标识符过长。我遇到最典型的一次，是一个团队把订单表命名为 order_management_daily_report_statistics，结果这个字段本身已经 38 个字节，Oracle 直接拒绝建表，最后只能改成 order_mgmt_daily_rep_stat。这就是命名的长度约束，它不是理论，是会真实影响到系统可用性的。

3. 八条命名规范，我压箱底的一套底牌

说完了合法性，接下来是重头戏：八条命名规范。这套规范我从几年前的第一个项目就开始总结，经历了反复踩坑之后才固定下来，现在不管进到什么团队，我第一件事就是把这几条贴到团队文档里。

八条分别是一句话：

1. 见名知意，名字要自解释
2. 选定一种命名风格，整个项目保持一致
3. 区分角色：变量、方法、常量、类各有各有约定
4. 控制长度，太长太短都是坑
5. 避免相近命名与语义冗余
6. 统一缩写和缩略词的处理
7. 用工具和插件去做强制校验
8. 为演进预留空间，该重构时就重构

下面我一条一条展开讲，每一条都会配上真实场景里的例子。

3.1 见名知意：名字要能自解释

这条是八条里最基础，也是最重要的。所谓“见名知意”，就是读到名字的瞬间，你不需要看注释、不需要看逻辑，就能大概猜出这个标识符是干什么的。我打个比方：如果一段代码里写 int d = s.getA() - s.getB()，你完全不知道 d 是什么；但如果改成 int discountAmount = salePrice - costPrice，那这段业务逻辑几乎不需要注释就能读懂。

日常代码里最常见的坏味道是单字母命名和缩写命名。x、y、tmp、data、info、obj 这类名字，在局部变量里偶尔出现可以容忍，但一旦进入方法参数、成员变量、接口返回值，就是灾难。我之前维护过一个老项目，有个工具类里有几十个 process(String a, String b, String c) 这样的方法，调用方根本分不清参数含义，只能一个方法一个方法去试。

真正好的做法是：如果逻辑需要注释才能看懂，先别急着写注释，看是不是名字没起好。比如下面的代码：

java复制// 不推荐
List<Map<String, Object>> list = getData();
for (Map<String, Object> m : list) {
    Object v = m.get("total");
    ...
}

// 推荐
List<OrderSummary> orderSummaries = getOrderSummaryList();
for (OrderSummary summary : orderSummaries) {
    BigDecimal totalAmount = summary.getTotalAmount();
    ...
}

第二种写法里，连变量类型都从 Map 换成了专门的 DTO，读代码的人不用再猜 m 里的 key 是什么，这种从根上减少理解成本的设计，才是命名规范想达到的目的。

3.2 选定一种命名风格，整个项目保持一致

命名风格看起来是百花齐放，主流的就是那么几种：驼峰（camelCase）、大驼峰（PascalCase）、下划线（snake_case）、短横线（kebab-case），还有全大写下划线（SCREAMING_SNAKE_CASE）。

不同语言和不同框架有自己的偏好。Java 的惯例是变量、方法用小驼峰，类用大驼峰，常量全大写下划线；Python 的惯例是变量、函数用下划线，类用大驼峰；CSS 类名习惯用短横线；Next.js 的文件名里有静态后缀约定。这些都不是法律，但它们代表了一个生态的默契。

比选哪种风格更重要的，是整个项目必须只选一种。我见过最混乱的项目，是一个 JavaScript 代码库里同时出现 getUserName、get_user_name、GET_USER_NAME 三种风格，原因是几个人从不同项目带了自己的习惯进来。这种项目里，哪怕你只是搜一个字段名，都要搜三次才能找全。

我的建议是：项目初始化时就把风格写进 README 或 .editorconfig 里。后面我会单独说工具强制这一条，这里先记住结论——风格的选择没有绝对的对错，但一致性是绝对的底线。

3.3 区分角色：变量、方法、常量、类各有各的约定

命名规范不是简单地“别用 a/b/c 就行”，不同角色的标识符，光看外观就应该能区分。这就像足球场上，你不能用同一个名字既当中锋又当门将。

在我的团队里，我要求代码里至少要能一眼区分出五种角色：

• 类名/接口名：大驼峰，名词或名词短语。例如 OrderService、UserProfile、PaymentGateway。
• 方法名：小驼峰，动词开头，后面跟宾语。例如 createOrder、calculateDiscount、sendNotification。
• 变量名：小驼峰，名词，语义明确。例如 orderList、totalPrice。
• 常量名：全大写下划线。例如 MAX_RETRY_COUNT、DEFAULT_TIMEOUT_MS。
• 枚举值：全大写下划线。例如 OrderStatus.PENDING_PAYMENT。

这里存在有最有争议的是布尔类型的命名。我强烈建议布尔变量和方法名用 is、has、can、should 这类助动词开头，因为它们在语义上天然会产生“是或否”的感觉。一个叫 flag 的布尔变量，别人看到时要猜它是“是否已删除”还是“是否可用”；一个叫 isDeleted 的布尔变量，就清晰得多。

java复制// 不推荐
boolean flag = order.isPaid();
if (flag) { ... }

// 推荐
boolean isPaid = order.isPaid();
if (isPaid) { ... }

方法也一样，isActive()、hasPermission()、canRefund() 读起来直接对应业务语义，比 checkState()、judge() 这类模糊动词高不知道多少个台阶。

3.4 控制长度：太长太短都是坑

命名长度是一条很微妙的线，因为同时存在两个方向的问题。

第一个问题是“太长”。现代 Java 写的 DTO 类名动辄就是 UserDetailInfoResponseVO，这种名字虽然语义清楚，但一旦标识符超过底层平台或数据库的硬性限制，就会直接报错。最典型的就是 Oracle 的 ORA-00972: 标识符过长。Oracle 的标识符上限是 30 字节，一个中文 GBK 编码占两个字节，英文占一个字节。你设计一个 order_management_daily_report_statistics 这样的字段名，在 MySQL 里没问题，迁到 Oracle 就必然炸。

我在实际项目里处理过不止一次这种问题。解决办法不是把名字缩写成面目全非的 odr_mgmt_dly_rpt_sta，而是要在可读性和长度之间找到一个平衡点。比如一个表格的业务含义是“订单管理日报表统计”，可以拆分语义层次：核心名词是 order，业务特征词是 daily_report，保留核心业务词，把不必要的 management、statistics 这种“流程词”收短，最终用 order_daily_report_stat 这种长度去控制。这个思路同样适用于 Java 类名和普通变量名，不要为了追求完整描述把每个单词都塞进去。

第二个问题是“太短”。a、b、tmp、res、obj 这种在循环里当临时变量用还能接受，但一旦出现在成员变量或方法参数里，就等于把理解成本转嫁给了下一个读代码的人。我自己的经验是，最稳妥的命名长度大约在 15 到 30 个字符之间，核心词本身能讲清楚业务语义，又不至于触发平台限制。

这里再补一个判断技巧：如果一个标识符长到需要换行才能写完，那大概率是语义层次没拆好，应该考虑把它拆成多个对象或方法，而不是继续憋一个超长名字。

3.5 避免相近命名与语义冗余

这一条是我在 code review 时最常点出来的问题之一。相近命名指的是几个名字长得很像、语义上容易混淆的标识符，它们往往是 bug 的温床。

举个例子，一个项目里同时有 userInfo、userInfos、userInfoDTO、userInfoVO，程序员在写业务代码时，稍不留神就会把 DTO 和 VO 混用。更可怕的是带数字结尾的命名，比如 data1、data2、orderInfo、orderInfo2，这种名字在复制粘贴时特别容易出低级错误，而且编译器不会提醒你。

语义冗余则是另一个常见问题，典型表现是“类型名混进变量名”。我看到过 String nameStr、List<User> userList、Map<String, String> configMap 这种命名，其实类型信息 IDE 里一眼就能看到，变量名里再重复一遍就是噪音。还有更过分的，类名已经叫 UserService，方法里再写 UserService userServiceService。

正确做法是让变量名承载业务含义，而不是类型含义。String name 比 String nameStr 好，List<User> users 比 List<User> userList 略好（但 users 更推荐复数）。判断标准很简单：把类型信息删掉之后，名字读起来通不通顺。

3.6 统一缩写和缩略词的处理

缩写看起来是小问题，实际能引发团队里最大的争论之一。典型冲突就是 HTMLParser 和 HtmlParser，getID 和 getId，URLUtil 和 UrlUtil。这些名字在同一个项目里出现两种写法时，搜索、重构、import 都会变得极其痛苦。

我的经验是：不要把整个缩写词大写放在变量名或方法名中间，因为这会让驼峰风格形同虚设。Java 社区比较主流的做法是，缩略词在大写驼峰开头时保持大写（比如 HTMLParser），在变量名和方法的驼峰中间时按单词处理（比如 parseHtml、htmlParser）。但更关键的是团队必须选定一个规则，然后通过工具统一执行。这个我会在后面第七条的 IDEA 插件里再次提到。

对于业务领域的专业缩写，比如 SKU、API、OrderNo，要专门定义一个团队术语表。我在项目里建过一个 naming-glossary.md，里面列了所有共享名词的规范写法，新同事进来先在文档里过一遍，比 review 时反复纠正高效得多。

3.7 用工具和插件做强制校验

人盯人是管不住命名规范的，最靠谱的是把规则固化到工具链里。这一步如果做不好，前面六条写得再漂亮也白搭。

在 Java 项目里，我常用的组合是 IDEA 插件 + Checkstyle + SonarLint。IDEA 自带的 Inspections 就会提示很多命名问题，比如 Class names should start with an uppercase letter；Alibaba Java Coding Guidelines 插件会把常见的命名规范问题也标出来；SonarLint 则能分析出更深层的坏味道，比如一个名字过长的变量存在多处引用时，它甚至会建议抽取成常量。

在 JavaScript / TypeScript 和 Next.js 项目里，ESLint 极其重要。你可以在 eslintrc 里配置 camelcase 规则，开启变量的驼峰校验；也可以配 @typescript-eslint/naming-convention 来做更精细的规则定制，比如强制接口用 I 开头，或者强制布尔变量前置 is、has。

javascript复制// ESLint 配置示例
module.exports = {
  rules: {
    camelcase: ['error', { properties: 'always' }],
    '@typescript-eslint/naming-convention': [
      'error',
      { selector: 'variable', format: ['camelCase', 'UPPER_CASE'] },
      { selector: 'function', format: ['camelCase'] },
      { selector: 'typeLike', format: ['PascalCase'] }
    ]
  }
};

工具的好处是它在所有阶段都统一执行，不会因为某个程序员心情不好就放松标准。老项目可以分步引入，不要一个 commit 全量改，容易引发大规模冲突和 merge 地狱。我的做法是先在新建文件上严格，再逐步对存量文件进行批量重构。

3.8 为演进预留空间，该重构时就重构

第八条看起来和前面几条不太一样，但它是保证命名规范长期有效的关键。命名不是一次性定稿，需求和架构一定会演进，所以标识符也要跟着进化。

我见过太多团队在项目初期定好命名规范，随着功能不断增加，老接口名和类名已经明显不合时宜，却因为“改动太大会影响调用方”而一直不处理。结果命名规范和业务语义渐行渐远，最后变成一套自欺欺人的白纸黑字。

正确的节奏是：发现不合理命名时，先看它的影响范围，如果只被一两个类引用，直接用 IDE 的全局重命名功能改了再说。IDEA 里按 Shift+F6 重命名类、方法、变量，它会自动同步所有引用，出错概率非常低。如果命名影响到了对外 API，可以保留旧方法，加 @Deprecated 注解，同时提供新命名方法，在下一个大版本里移除旧的。这样既能保持兼容，又不至于让坏命名永久沉淀。

4. 让规范落在实处：一整套具体场景的命名方案

前面八条偏原则，这一章我把它下沉到具体场景里，把方法命名规范、分支命名规范、Next.js 项目文件命名规范和安全标识符的命名管理都过一遍。这些都是高频场景，也是最容易出问题的区域。

4.1 方法命名规范：把动词用对，整个代码就像讲故事

方法命名是我平时 review 得最多的模块。方法名的核心逻辑是：动词开头，接着宾语，能准确描述这个方法做了什么。比如 getUserById、createOrder、deleteExpiredToken，一看就懂。如果动词选得模糊，比如 handleData、doWork、dealWithXxx，读者就会满脑子问号。

对于返回布尔类型的方法，我推荐强制使用这些前缀：

• is：表示状态判断，isActive()、isDeleted()。
• has：表示持有关系，hasPermission()、hasChildren()。
• can：表示是否具备能力，canRefund()、canModify()。
• should：表示是否应该执行，shouldRetry()。

对于创建类方法，要区分 create、build、new 这些词的细微差别。createOrder 表示业务意义上的创建订单；buildDemoData 表示构建测试数据；toDTO、fromEntity 这类转型方法用 to 或 from 开头，语义最自然。

另外，在写单元测试时，我推荐用 方法名_条件_预期结果 或者 given...when...then... 风格命名。比如测试方法 refund_whenOrderAlreadyShipped_thenFail，这种方法名可以把测试意图说得很清楚，看报告时不用一个个点开代码。

4.2 分支命名规范：给代码仓库也立规矩

Git 分支名也是标识符，但它常常被人遗忘。分支名里如果全是 test、fix2、dev-final-again，住进仓库的人一定会想骂人。我的分支命名标准格式是：

code复制类型/归属/描述

其中类型常用 feature、bugfix、hotfix、chore、docs、refactor 六个前缀。描述用英文短横线去连接，尽量用业务功能名，不用人名和日期。比如 feature/order-cancel、bugfix/payment-timeout-retry、chore/upgrade-eslint。

这种分支命名的好处是很大：CI/CD 可以根据分支前缀自动决定要不要触发部署；版本发布的 changelog 也可以靠分支前缀自动汇总；而且分支合并到主干后，代码提交记录本身也成为一份可读性很高的项目日志。我还见过不少团队在这种规范上更进一步，要求 commit message 也能对应相应分支，例如 feat(api): add order cancel endpoint，效果很显著。

4.3 Next.js 项目里怎么套用命名规范

Next.js 的类型非常注重文件路径，文件名本身就是路由结构和组件粒度的标识，所以它的命名规范有自己的特点，不能照搬 Java。

在 Next.js 项目里，文件标识符遵守几个优先级：

• 框架保留字文件（page.tsx、layout.tsx、loading.tsx、error.tsx、route.ts）使用固定小写名称，不能改。
• 组件文件用大驼峰，例如 components/UserCard.tsx、components/Sidebar.tsx。
• 非组件模块，比如工具函数、hooks、接口定义，用小驼峰或者短横线，例如 lib/formatDate.ts、hooks/useAuth.ts、api/order.ts。
• 目录通常用短横线或小驼峰，按团队约定统一。

特别提醒一下，不要试图用 page.tsx 以外的自定义文件名去当路由，这样一方面会跟 Next.js 的文件路由机制打架，另一方面同事一看文件名就能猜出该文件是不是一个 Page，这本身就是标识符应该具备的“角色区分”功能。

4.4 安全标识符的命名管理

在安全或者运维场景里，标识符还有另一层含义：像 API Key、Token、密钥 ID、SID 这类安全标识符，它们的命名比常规变量名更讲究，因为暴露出来的话，风险会直接放大。

这里说的“安全标识符”在项目里通常指的是存储在配置中心或环境变量里的敏感项，例如 ALIYUN_ACCESS_KEY_ID、STRIPE_SECRET_KEY、JWT_SIGNING_SECRET。我强烈建议这一类标识符遵守三个规则：第一，环境敏感信息必须在名字里带环境前缀，比如 DEV_、TEST_、PROD_，避免把开发环境密钥策划到生产环境；第二，绝对不能直接在代码里写硬编码的密钥值，要么从环境变量读取，要么从密钥管理服务拉取；第三，定义一个过期轮换周期，并在名字或描述里标记过期时间，方便后续清理。

有些项目里还会出现 Windows 系统的“安全标识符”（SID）这种概念，本质也是一个唯一标识对象的编码。这类标识符通常由系统生成，不建议手动取名拼接，而是尽量用系统提供的高熵随机值，因为你永远不知道手动起的名字会不会跟现有体系冲突。无论哪种情况，对安全标识符的处理原则永远是：先考虑唯一性、不可枚举性，再考虑可读性。

5. 常见报错和排查笔记

这一章我把几个真实遇到过的报错和排查过程整理出来，当作速查表使用。这些都是热词里出现的高频问题，也是日常工作中确实能遇见的硬伤。

5.1 ORA-00972：标识符过长

这个错误从 Oracle 数据库来的，完整报错是 ORA-00972: identifier is too long。原因基本只有一个：你创建的数据库对象名字超过 30 字节。

排查思路很简单，先看报错中的中符号名称，再数一下它的字节数。英文标识符一个字符一个字节，中文标识符如果是 GBK 编码则一个字两个字节，UTF-8 更复杂，一个字可能占三四个字节。比如 订单_每日统计_汇总表 这种中文字段名，在 Oracle 里很容易直接超标。

解决办法分两层。第一层，如果只是个别对象超长，直接改名，在保留语义的前提下压缩单词。第二层，如果是整个项目的命名习惯导致的集体超长，那就要回到团队规范上，把“标识符长度上限”写进设计规范，并且在数据库建模评审时加入这个检查项。我自己习惯在 CI 里跑一个简单的 SQL 查询，扫描所有用户表对象名长度，超过 30 字节直接告警。

5.2 “未定义的标识符 true”

这个报错在 C/C++ 或者某些脚本语言环境里会遇到，报错形式是 'true' was not declared in this scope 或者 Uncaught ReferenceError: true is not defined 之类。很多人第一反应是“true 怎么还可能未定义”，其实本质原因通常是两种：一是你所在的语言没有把 true 定义为关键字或内置字面量，它只是一个普通标识符；二是你把 true 写成了变量名，或者试图给 true 赋值。

从命名规范角度看，这里最大的教训是：在写代码之前，先确认你常用的 true、false、null、undefined 这些字面量在当前语言里是否被保留。很多准新人在从 JavaScript 转到 PHP 或者跨语言切换时，最容易被这类“看起来通用、实际上有差异”的词纠缠。规范的做法是，在任何环境里都不要把 true、false、null 这类字面量当作标识符或变量名使用，哪怕编译器不报错，也会造成语义误解。

5.3 大小写不一致引发的“未定义”类问题

标识符大小写问题是我在跨平台团队里发现的高频坑。Java 本身区分大小写，userName 和 Username 是两个完全不同的标识符；而文件系统在 macOS 上默认大小写不敏感，在 Windows 上如果分区的格式化是大小写敏感模式，又会变得敏感。于是经常出现本地能跑、CI 上爆出文件找不到的错误。

这类问题要从命名规范源头堵：定义目录和文件名风格时，强制全项目统一大小写规则，比如所有组件文件一律大驼峰开头，所有工具库一律小驼峰开头。在 CI 脚本里加一个文件命名检查也可以，用 dir 或 grep 找出不符合规则的文件名，直接构建失败。

5.4 命名规范和架构不一致时怎么收场

最后一种“报错”不是编译报错，而是代码评审时被反复提出的结构性问题。比如你的类叫 UserService，里面却夹杂了订单、支付、消息通知的很多方法；再比如你的变量名都是 data 和 info，方法体有 200 行，怎么改名都救不回来。这种时候，命名规范已经只是表面问题了，深层其实是职责划分和抽象粒度出了偏差。

我的排查经验是，先借助 IDE 的分析能力。IDEA 里选中一个类，按 Alt+F7 查看它的所有调用关系，评估方法职责是否内聚；再按 Ctrl+Alt+Shift+T 调出重构菜单，看哪些方法可以抽取到别的类里。先把职责拆干净，再对暴露的公共接口改命名，最后再处理局部变量。这个顺序一定不要反过来，否则你会陷入“改了名字还要回头改逻辑”的泥潭。

6. 我经常分享的一套团队落地技巧

文章最后，我不打算做什么宏大总结，就想把实践中反复验证过的几个具体技巧再啰嗦一遍。

第一，命名规范文档不要写成 100 页的制度，没有人会看完。我推荐只保留一页 A4 纸，核心是八条规则加一份术语对照表。术语对照表反而比规则更有用，因为业务词汇一旦统一，命名就成功了一大半。第二，新人入职第一天，先让他花半小时读术语表和命名规范，再安排他看代码。比让他直接读代码效果要好很多。第三，每次 code review 时，命名问题专门留一个频道来讨论，不要混在逻辑变更里。否则整个 review 过程会偏题，最后也没有结论。

还有一个很实际的经验：当你发现项目里有个名字自己都解释不通时，不要等到“以后有空再改”。顺手就改，只要改动范围可控。这三个字“顺便改”积累下来，一个糟糕的代码库是可以慢慢被救回来的。如果每次都想着“以后统一处理”，那个“以后”大概率永远不会来。

标识符的命名规范听起来是个特别小的话题，但它几乎是判断一个团队工程素养最直接的信号。看到干净的命名，你能感受到背后的人在乎后来者；看到满屏的 a、b、temp，你也知道维护这套代码会是什么体验。希望这篇整理能让你少踩几个坑。