需要审查或改进变量、函数、类等命名时，用命名分析找出模糊…

在代码审查或重构时分析变量、函数、类、文件、数据库、API 等命名，按语言约定和项目规范指出问题并给出更好的替代名称。

适用场景

解决思路

1. 分析现有名称，覆盖：变量与常量、函数与方法、类/接口/类型、文件与目录、数据库表与列、API 端点。
2. 识别命名问题：不清晰或模糊的名称、掩盖含义的缩写、不一致的命名约定、名称与行为不符的误导性名称、过短或过长的名称、匈牙利命名法误用、循环外使用单字母变量。
3. 检查约定：语言特定约定（camelCase、snake_case、PascalCase）、框架约定（React 组件、Vue props）、项目特定模式、行业标准。
4. 提供建议：更好的替代名称、每个建议的理由、一致性改进、上下文适当性。
5. JavaScript/TypeScript 命名约定：变量/函数用 camelCase；类/接口用 PascalCase；常量用 UPPER_SNAKE_CASE；私有字段用 _prefixUnderscore 或 #privateField；布尔用 is、has、can、should 前缀。
6. Python 命名约定：变量/函数用 snake_case；类用 PascalCase；常量用 UPPER_SNAKE_CASE；私有成员用 _prefix_underscore；布尔用 is_、has_、can_ 前缀。
7. Java 命名约定：变量/方法用 camelCase；类/接口用 PascalCase；常量用 UPPER_SNAKE_CASE；包名用 lowercase。
8. Go 命名约定：导出标识符用 PascalCase；未导出标识符用 camelCase；首字母缩略词全部大写，例如 HTTPServer 而不是 HttpServer。
9. 修复过于模糊的名称：process(data) 改为 processPayment(transaction)；getData() 改为 getUserProfile()；temp 改为 previousValue。
10. 修复误导性名称：名称应反映实际行为，例如 getUser 有副作用时改为 fetchAndUpdateUserLogin。
11. 修复缩写：usrCfg 改为 userConfig；calcTtl(arr) 改为 calculateTotal(amounts)；保留业界熟知的缩写，如 htmlElement、apiUrl。
12. 修复布尔命名：login 改为 isLoggedIn；status 改为 isUserValid；使用 hasPermission、canEditPost、shouldShowNotification 等清晰布尔名。
13. 修复魔法数字：把 if (age > 18) 改为 LEGAL_AGE = 18；把 setTimeout(callback, 3600000) 改为 ONE_HOUR_IN_MS = 60 * 60 * 1000。
14. 调用方式：使用 @naming-analyzer 分析；@naming-analyzer src/ 分析目录；@naming-analyzer UserService.js 分析文件；@naming-analyzer --conventions 检查约定；@naming-analyzer --fix-all 自动修复。
15. 生成命名分析报告，Summary 包含：Items analyzed、Issues found、Critical、Major、Minor 统计。
16. 按严重性分组报告：Critical 为误导性名称；Major 为不清晰/模糊；Minor 为约定违规。
17. 每个问题项报告：Current 当前名称、Issue 问题、Severity 严重性、Suggestion 建议、Reason 理由。
18. 汇总 Convention Violations：布尔前缀不一致时，统一用 is 表示状态（isActive、isVisible）、has 表示拥有（hasPermission、hasError）、can 表示能力（canEdit、canDelete）、should 表示决策（shouldRender、shouldValidate）。
19. 汇总 Convention Violations：命名约定混用时，例如 JavaScript 中混用 camelCase 和 snake_case，统一转为 camelCase。
20. 给出 Suggested Renaming 并按优先级排列：高优先级为误导或关键问题；中优先级为清晰度问题；低优先级为约定问题。
21. 命名模式：函数/方法用动词，如 get、set、create、update、delete、fetch、calculate、validate，并体现明确动作，如 sendEmail()、parseJSON()、formatCurrency()。
22. 命名模式：类用名词，如 UserService、PaymentProcessor、EmailValidator；避免泛化，除非必要不要用 Manager、Helper、Utility。
23. 命名模式：变量用名词或名词短语，如 user、emailAddress、totalAmount；要描述性强，如 userList 而不是 list、activeUsers 而不是 users2。
24. 命名模式：常量用全大写加下划线，如 MAX_RETRY_ATTEMPTS、DEFAULT_TIMEOUT；包含单位，如 CACHE_DURATION_MS、MAX_FILE_SIZE_MB。
25. 命名模式：布尔用问句形式，如 isValid、hasPermission、canEdit；优先肯定形式，如 isEnabled 而不是 isDisabled。
26. 提供重构脚本：重命名所有建议项、更新所有引用、保持 git 历史、生成迁移指南。
27. Best Practices DO：使用完整单词而不是缩写、具体且描述性强、遵循语言约定、使用一致模式、让布尔含义明显、常量包含单位。
28. Best Practices DON'T：除循环 i、j、k 外不使用单字母、不使用 data/info/temp/x 等模糊名称、不混用命名约定、不使用误导性名称、不过度缩写、现代代码中不使用匈牙利命名法。
29. 按决策树选择命名：是布尔则用 is/has/can/should 前缀；否则是函数则用动词短语；否则是类则用名词 PascalCase；否则是常量则用 UPPER_SNAKE_CASE；否则用描述性名词 camelCase/snake_case。
30. 遵循注意事项：清晰优先于简短；上下文重要，循环计数器可以用 i、j；html、api、url、id 等知名缩写可以保留；项目内一致性比完美命名更重要；理解提升后重构名称；用 IDE rename 重构安全更新所有引用。

适用边界 · 注意事项

• 循环计数器 i、j、k 等局部短变量不必强行重命名。
• html、api、url、id 等行业广泛认可的缩写无需展开。
• 当项目已有稳定命名约定时，优先保持项目内一致性，不要仅按语言通用规范强行改名。