我所理解的代码风格最佳实践

改一段陌生代码时，我通常先找到触发它的按钮、调用点或报错，再沿着名字和引用往里走。这个过程有时很顺，有时得先猜第三个参数的意思，再经过一层转发，最后还要弄清两个叫 profile 的值分别是谁的。写代码时省下的几行，维护时可能要花好几次跳转才能补回来。

我理解的代码风格，包含命名、调用方式、模块的公开入口，也包含状态放在哪里、目录怎样表达归属。格式可以统一交给工具。剩下的选择，我通常用一个具体问题来衡量：下一次改需求时，读者能不能从调用处找到真正负责这件事的代码？以下做法是我在自己主导的项目里采用的默认。接手已有项目时，我会先沿用它稳定的约定。涉及数据正确性、框架运行条件或公开契约时，则要按具体行为验证。

由于篇幅问题，全文分成四部分来讲。

第一篇《JavaScript 代码怎样从调用点读下去》从一个订单查询调用出发，讨论怎样给参数、布尔值和单位命名，什么时候把逻辑留在原地，以及哪些导出值得让其他模块依赖。

第二篇《Vue 组件与 composable 的职责边界》沿着资料卡的调用点往下读，区分组件局部状态、业务数据与派生值，再看 composable 的参数、返回值和私有实现怎样一起演进。

第三篇《Nuxt 页面、目录与自动导入》用一个 Nuxt 4 个人主页串起路由、页面组件和 composable，说明目录前缀怎么用、哪些依赖适合自动导入，以及怎样检查框架生成的入口。

第四篇《哪些项目约定值得写成 Lint》从一条私有导入约定出发，讨论格式化、Lint、专项检查和 review 各自需要什么证据，再把一条规则从试跑推到 CI。

涉及严格模式、类型建模和类型检查的内容，可以接着读《我所理解的 TypeScript 最佳实践》。