无障碍编程：变量命名中的视障友好之道

　　去年11月那阵子，我原以为“视障友好变量命名”就是个政治正确的噱头——直到跟老陈撕了一下午代码。这货现在做无障碍开发，非说变量名得用“听觉友好”的写法，比如把“userAge”改成“user_age_in_years”，说这样读屏软件能念得更清楚。我说你疯了吧？谁家变量名带下划线还加后缀？结果他当场翻出IDE的语音提示，念到“user_age_in_years”时，那语调慢得跟深蹲架上的杠铃片往下掉似的——“用户——年龄——以——年——为单位”。器械区镜子上有道划痕，我盯着那道痕想，这他妈能提升效率？

　　但老陈甩了组数据：他们团队重构了三个模块，把所有变量名从驼峰式改成“描述性下划线”后，视障开发者的代码评审通过率涨了40%。我第一反应是扯淡——这就像说深蹲时戴护膝能多蹲20kg，结果他翻出GitHub的提交记录，确实有视障开发者在issue里写：“以前变量名念成‘userage’，分不清是user和age还是userAge，现在念成‘user_age’，脑子不用转了。”饮水机旁堆的一次性杯被风吹倒几个，我弯腰捡杯子时突然意识到，这他妈不就是“优胜劣汰”吗？变量名最终是给人用的，不管用眼睛看还是用耳朵听，能让人更快理解的就是好命名。

　　可问题来了：怎么定义“听觉友好”？老陈说他们搞了个“读屏友好度评分表”，比如变量名长度超过15个字符扣分，连续三个元音字母扣分（因为读屏软件会拖长音），数字和字母混用扣分（比如“user123”会被念成“用户一二三”）。我听着像健身教练给会员定饮食计划——这不能吃那不能吃，最后会员饿得蹲在深蹲架旁啃蛋白棒。前台在煮咖啡，香味飘过来，我说你这套规则太死板了，比如“userAge”和“user_age_in_years”，前者念快了可能漏“A”，后者念全了得三秒，但后者在复杂逻辑里反而更清楚。老陈拍桌子：“所以得看场景！就像练腿日和练胸日能一样吗？”

文章配图，仅供参考

　　跑题说句，上周带会员练硬拉，他非说“杠铃片得对称装”，我原以为他懂力学，结果他是指“颜色得对称”——左边红片右边也得红片，说这样“看着舒服”。这跟变量命名有啥关系？关系就是：人总会被习惯绑架。就像很多开发者觉得“i”是循环变量的“标准写法”，但视障开发者听不到“i”的上下文，它就是个无意义的音节。老陈的团队做过实验：让视障开发者听两段代码，一段用“i”，一段用“current_index”，听完画流程图，后者画的准确率高30%。地胶被踩出的黑印里混着镁粉，我蹲下摸了摸，突然觉得这像代码里的“坏味道”——平时看不见，但会影响整体质量。

　　当然，不是所有变量都得改。老陈说他们只改“关键路径”上的变量，比如循环变量、状态标志、配置参数。像“temp”“res”这种临时变量，读屏软件念出来是“腾普”“瑞斯”，视障开发者自己知道是啥，不用改。这就像练臀时，不是所有动作都得上大重量——山羊挺身用自重，深蹲才上杠铃片。但问题又来了：怎么定义“关键路径”？老陈的团队用代码覆盖率工具，只改被执行超过50%的代码里的变量名。我听着像私教课消课——得先记录会员来了多少次，再决定怎么练。

　　最扯的是，他们还搞了“变量名方言”。比如有些视障开发者习惯英式发音，有些习惯美式，读屏软件念“_”的方式不一样——英式会念“underscore”，美式可能念“underline”。所以变量名里尽量少用“_”，改用“camelCase”或“snake_case”的混合（比如“userAgeInYears”）。我原以为这是过度优化，结果老陈翻出段录音：一个视障开发者念“user_age_in_years”时，因为“_”太多，读屏软件卡顿了两次，他得手动暂停再继续。跑步机电机的嗡声里，我听到自己说：“这他妈比深蹲时杠铃片晃还烦人。”

　　现在的问题是：普通开发者怎么写“视障友好”的变量名？老陈的答案是“先保证自己能看懂，再考虑读屏软件”。比如“userAge”可以保留，但得在注释里写清楚“// 当前用户的年龄（以年为单位）”；如果变量名本身能包含信息，比如“userAgeInYears”，就不用注释。这像健身教练教新手——先学会标准动作，再考虑进阶技巧。但矛盾在于：注释是给眼睛看的，变量名是给耳朵听的，两者得兼顾。更衣室的门又“哐当”响，我提高嗓门：“那团队里得有视障开发者参与评审？”老陈点头：“必须的，就像练CrossFit得有教练盯着，不然容易代偿受伤。”

　　我承认，这套规则不是银弹。比如有些视障开发者习惯用“数字+字母”的变量名（比如“u1”“u2”），读屏软件念成“你一”“你二”，他们自己能理解，但普通开发者看了懵逼。老陈说：“所以得统一标准，就像健身房里不能有人用自由重量，有人用固定器械——得有基本规则。”可问题是，规则谁定？是视障开发者，还是普通开发者？或者像健身行业的“国际标准动作”一样，找个中间方案？

　　最后老陈说了句让我后怕的话：“十年后，可能所有开发者都得考虑无障碍编程，就像现在所有网站都得做响应式设计。”我盯着器械区镜子上的划痕想，这划痕以前没这么深啊？可能每天被杠铃片蹭的。代码里的“坏变量名”也像这划痕——平时看不见，但积累多了，整个系统就废了。所以，变量名优胜劣汰的规则可能很简单：能让人（不管用眼睛还是耳朵）最快理解的，就是好命名。至于具体怎么写？可能得像健身计划一样——先试，再调，最后找到适合自己的“重量”。

　　现在我在自己项目里也加了条规则：关键变量名得能“念出来”。比如“userAge”可以，“userAgeDataModel”不行——后者读屏软件念完得五秒，脑子早转不过来了。至于团队里有没有视障开发者？暂时没有，但老陈说：“可以先用读屏软件自己听——就像练前先热身，自己先感受下。”饮水机旁的一次性杯又倒了，我懒得捡，心想：变量名这事儿，可能就跟这杯子一样——没人注意时，它就是个杯子；有人较真时，它得站得稳。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!