【第3507期】基本属实的命名规则

正文

请到「今天看啥」查看全文

那这个数据是从哪里来的呢？

 trip.member_requested_gear = memberRequestedGear

呃，好吧，我可能是想在 JavaScript 和 HTML 中保持各自的命名风格（JS 用驼峰，HTML…… 比较随意）。那 memberRequestedGear 是怎么来的？

const memberRequestedGear = gear.getIndividualRequestedGear(req.db, tripId)

天哪，又是 “Individual Gear”？也就是说，命名在不同地方反复切换？

当然，这个函数最终查的是名为 member_gear_requests 的 SQL 表：

exportfunctiongetIndividualRequestedGear(db, tripId){
// 查询大致如下：
// SELECT ...
// FROM member_gear_requests
}

总结一下，这个概念 —— “学生为自己申请的装备” —— 在我的代码里出现了这些不同的名称：

• Individual Gear
• member_requested_gear
• memberRequestedGear
• getIndividualRequestedGear
• member_gear_requests

结果比我想象的还混乱（而且这段代码全是我自己写的）。

当然有些差异是必须的。前端显示给用户的信息应该更友好，比如不会在

标签里用蛇形命名。但如果我一开始就选对了数据库表名，也不用执着于用驼峰命名变量，就可以做到：

• 前端显示为 “Individual Gear”
• 函数叫 getIndividualGearRequests
• 数据库表及变量名统一为 individual_gear_requests

如果你比我更坚定，还可以坚持连函数名都用蛇形命名。但我个人觉得函数和变量在概念上已经够不同了，不必强求。不过，随你喜欢！

命名不一致背后的更深原因：建模模糊

很多时候命名混乱的背后，不是风格问题，而是建模不清晰。

“member gear” 和 “individual gear” 其实指的是同一个东西，但我当时显然没彻底想明白，导致数据库、后端、前端叫法各不相同。

我们以为是在写代码，其实是在构建一个对现实世界的抽象模型。而大多数开发者并没有接受过 “建模” 的系统训练。命名之所以难，是因为我们常常没弄清楚这个概念到底是什么。

领域驱动设计 （DDD）提出 “通用语言” 原则：团队中所有人 —— 产品、设计、开发、测试 —— 对同一个业务概念要用统一的名称。这个统一的名字贯穿数据库、API、代码、文档、会议和注释。

如果你在接口里叫它 user_items ，数据库表是 member_gear_requests

请到「今天看啥」查看全文