由 dawei 无障碍编程不是附加功能，而是尊重每位开发者认知方式的基本承诺。视障开发者依赖屏幕阅读器将代码转为语音或盲文，而变量命名恰恰是他们理解逻辑流的第一道门槛。
模糊缩写是隐形障碍。当屏幕阅读器念出“usr”“tmp”“idx”，它无法传递语义——这不像视觉者能靠上下文快速推测。更糟的是，“usr”可能被读作“user”或“U-S-R”，歧义迫使开发者反复停顿、回溯、验证，打断思维连续性。用完整单词如“currentUser”“temporaryFile”“elementIndex”，让语音输出本身就能承载意义。
创意图AI设计，仅供参考
驼峰命名中的大小写边界对屏幕阅读器至关重要。良好的命名会主动强化语音切分：例如“maxRetryCount”自然被识别为“max retry count”，而“maxretrycount”则易被连读成“maxretrycount”，失去语义颗粒度。避免下划线也不利于部分阅读器的停顿处理，驼峰式已成为事实标准。
避免纯数字或位置标识符。“data1”“item2”在语音中毫无区分度，也掩盖了角色意图。换成“pendingOrderList”“failedApiResponse”等基于职责与状态的命名，让听者无需翻阅上下文即可把握变量用途。
类型暗示需谨慎。像“strName”“iCount”这类匈牙利命名法，曾为静态类型语言提供辅助，但在现代IDE和屏幕阅读器支持类型提示的今天，反而增加冗余音节，削弱核心语义。“userName”已足够清晰，“stringUserName”反而模糊重点。
命名即注释，而注释应当可听。一段能被顺畅朗读、无歧义、有逻辑的变量名，本身就是对视障同事最务实的协作礼遇。它不增加代码行数，却显著降低认知负荷；它不要求特殊工具，只呼唤一次命名时的片刻共情——那0.5秒的停顿，决定别人能否平等地听见代码的逻辑心跳。