合理命名变量，提升代码可读性，减少注释依赖

变量命名绝非小事，而是直接影响代码可读性、协作效率与长期可维护性的核心实践：精准、完整、带业务语境的名称（如 `isEmailVerified`、`userBalanceInCents`、`currentUserProfile`）能让逻辑自解释，自然淘汰冗余注释；作用域决定命名粒度——局部用简名，跨模块必用无歧义全称；而命名更需持续演进，随变量职责变化而重构。写代码不是让机器读懂，而是让三天后的自己和团队成员一眼会意——多敲几个字母的代价，远小于反复猜测、查文档、踩布尔陷阱的时间成本。

变量名本身能表达逻辑，就别靠注释补救

很多注释其实是“变量名没说清，只好用文字再解释一遍”。比如 const d = new Date().getDate()，后面跟一句 // 获取当前日期，本质是 d 这个名字没承担起说明职责。换成 const todayDate = new Date().getDate()，注释自然消失。命名不是为了“让机器运行”，而是让下一个人（包括三天后的你）扫一眼就懂上下文。

用完整单词+业务语境组合命名，避免缩写猜谜

常见错误是把 userInf、tmpObj、resData 当成省事写法，结果每次读到都得停顿半秒去脑补。实际开发中，多敲几个字母的成本远低于反复查上下文的理解成本。

• userInf → 改为 userInfo 或更具体如 currentUserProfile
• tmpObj → 明确用途，如 cachedApiResponse、normalizedFormData
• resData → 拆解来源与含义，如 apiResponsePayload、paymentResultBody

关键点：命名里带动词或名词修饰（is、has、should、validated、pending）比纯名词更能传递状态，比如 isEmailVerified 比 emailStatus 更少歧义。

区分作用域，小范围可简，大范围必须全

函数内部循环里的临时计数器用 i、idx 没问题；但模块顶层、API 响应解析层、状态管理中的字段，必须用完整、无歧义的名称。否则一旦跨文件引用，data 到底是后端原始响应、还是前端处理过的视图模型，根本分不清。

• 局部作用域（函数内）：item、acc、sum 可接受
• 模块/类/接口级：orderLineItems、shippingAddressValidationErrors、userPreferenceSettings
• 避免靠注释“打补丁”：比如 const v = getVal(); // 用户余额（单位：分），不如直接写 const userBalanceInCents

常量和布尔值命名要自带判断语义

布尔变量名如果不能一眼看出真值含义，就等于埋雷。比如 const loading = true，没人知道这是“正在加载”还是“加载完成”。同理，常量若只写 MAX_RETRY，不说明是次数、时间还是字节数，后续使用时就得翻文档。

• 布尔变量强制加 is/has/can/should 前缀：isFormValid、hasUnsavedChanges、shouldShowTutorial
• 常量带上单位或约束类型：MAX_RETRY_ATTEMPTS、DEFAULT_TIMEOUT_MS、MIN_PASSWORD_LENGTH
• 别用 FLAG_XXX 这类泛化前缀，它不提供任何业务信息

最常被忽略的一点：命名不是一次性的活——当一个变量从局部提升为模块级、或从简单值变成对象结构时，必须同步重审名字。比如原先是 userName，后来扩展成包含昵称、正式名、显示名的对象，还叫 userName 就会误导所有人。

以上就是《合理命名变量，提升代码可读性，减少注释依赖》的详细内容，更多关于的资料请关注golang学习网公众号！