代码不会说话？让 JS 函数名替你开口

接手旧项目时，最让人头大的往往不是逻辑复杂，而是看到一堆 doSomething()、handleFunc() 和 processData()。当你不得不花半小时去猜测这个函数的真实意图，甚至要翻源码才能确认它有没有产生副作用时，维护成本就已经失控了。函数命名本质上是人与人的沟通，优秀的命名能让代码自文档化，减少注释依赖。

日常开发中，动词的精准选择直接决定了语义的清晰度。如果函数负责获取数据但返回新对象，用 getData；如果只是引用当前状态而不计算，考虑 getCurrentStatus。很多新人喜欢滥用 get，导致 getHtmlContent 明明是从服务器请求回来，看起来却像本地读取。区分“查询（Query）”与“命令（Command）”是关键界限：查询不应修改系统状态，而命令一定会改变某些东西。例如，checkValidity 是纯粹的判断，而 validateForm 则隐含了填写错误信息或阻止提交的副作用。

遇到布尔值返回值时，命名更要小心。isValid、hasPermission、canSubmit 这种前缀能让人一眼看清 if 里的条件含义。如果名叫 result 或者 status，后续阅读代码的人还得去猜 0 代表成功还是失败。确保布尔函数的名字带有明确的是非预期，这能有效降低认知负荷。特别是在团队协作中，统一约定好 is 开头表示属性检查，can 开头表示权限校验，能大幅减少歧义。

异步处理在现代前端中无处不在，这里最容易埋雷。有些开发者为了省事，把 Promise 包装在看似同步的函数里。如果函数内部有异步请求，建议在命名上保留异步特征或直接通过类型提示体现，比如 fetchUserAsync 或在 TypeScript 中明确标注 Promise<User>。更进阶的做法是在调用处体现语义，当你在代码中写下 await login() 时，必须清楚知道它在网络请求，而不是本地验证。不要让命名掩盖了执行流程的真相。

作用域也是命名的隐形边界。在组件内部，submit 通常被理解为“提交表单”，不需要加 formSubmit 这种冗余前缀。但在工具库层级，为了冲突避让，utils.stringify() 就必须比全局的 stringify() 更安全。根据函数所在的上下文模块调整命名粒度，公共库追求唯一性和描述完整，业务组件侧重简洁和场景感。不要在每个单词前面都堆砌模块名，那会让代码变得臃肿不堪。

其实，最好的命名标准往往来自团队的共识。与其纠结是驼峰还是下划线，不如先统一谁来决定“什么是好的名字”。遇到拿不准的情况，试着把这个名字读给别人听，如果对方需要停顿思考超过三秒，说明它还不够直观。花时间推敲一个变量名或函数名，可能只需要几分钟，但这笔投资会在未来无数次调试和重构中加倍回报。别让技术债堆积在那些模糊不清的名字里，从现在开始，让每一个函数名都成为清晰的路标。