大型javascript项目变量命名需统一用小驼峰、布尔值加is/has/should前缀，常量全大写下划线，dom加el/前缀，配合eslint、prettier和typescript约束，并通过文档与code review保障落地。
在大型 JavaScript 项目中，变量命名和声明不是“写对就行”的小事，而是影响协作效率、代码可读性与长期维护成本的关键环节。核心在于统一、语义化、可推断——让任何人打开任意文件，都能快速理解变量用途、类型和作用范围。
统一使用小驼峰命名（camelCase）并严格区分类型语义
所有普通变量、函数、参数、对象属性都用小驼峰：第一个单词小写，后续单词首字母大写，如 userName、isModalOpen、fetchUserProfile。禁止出现下划线（user_name）、全大写（USERNAME）、连字符（user-name）或首字母大写（UserName，那是类名用的）。
特别注意布尔值必须带语义前缀：
- is + 形容词：表示状态，如 isLoading、isValid
- has + 名词：表示拥有关系，如 hasPermission、hasUnsavedChanges
- should + 动词：表示条件判断意图，如 shouldRetry、shouldAutoSave
- 避免模糊命名如 flag、status、enabled（没说明“谁”的状态或“什么”被启用）
按用途和生命周期选择声明方式与命名风格
大型项目中变量不是“随便 let 一下”，而要根据作用域、可变性、用途做分层管理：
- 常量（运行时不变）：用 const 声明，全大写+下划线，如 API_BASE_URL、MAX_RETRY_COUNT、DEFAULT_PAGE_SIZE
- 配置项或环境变量：即使可变也建议 const + 对象封装，如 const APP_CONFIG = { theme: 'dark', debug: false }
- 临时计算值 / 循环变量：仍用小驼峰，但允许简短且上下文明确，如 index、item、chunk（禁用 i、j，除非是极简 for 循环且无嵌套）
- DOM 元素引用：加前缀强化意图，如 btnSubmit、inputSearch、elHeader
- Promises 或异步结果：可加后缀提示，如 userPromise、profileData（而非 res 或 data）
借助工具链实现自动化约束
靠人盯无法保障千行级项目的命名一致性。必须引入工程化手段：
- 用 ESLint 启用 camelcase、no-unused-vars、no-shadow 等规则，并自定义布尔变量前缀检查（如要求 is*、has*）
- 用 Prettier 统一格式，避免因空格/换行差异引发命名争议
- 配合 husky + lint-staged，在 git commit 前自动校验并修复基础命名问题
- 在 TypeScript 项目中，利用类型标注进一步约束变量含义，例如 const isLoading: boolean = true 能在编辑器中即时反馈命名是否符合布尔语义
团队协同需配套文档与审查机制
规范落地不能只靠工具。需要明确写入团队《前端开发手册》，包含：
- 命名决策树：比如“这个变量存的是用户列表？→ 用 users；如果是单个用户对象？→ 用 currentUser；如果是从 API 拿到的原始响应？→ 用 apiUserResponse”
- 反例集锦：列出高频错误命名（如 data、temp、obj）及修改建议
- Code Review Checklist 中加入命名项：“变量名是否可读？是否体现类型和用途？布尔值是否有 is/has 前缀？”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
