无障碍编程：变量命名中的视障友好设计

　　去年三月那把，我段位其实不高，但那场复盘真让我记到现在——队友老张在语音里骂了二十分钟变量命名，说视障同事对着他的代码抓耳挠腮，屏幕朗读器念到“tempVar3”的时候，人家直接摔耳机走了。我当时还笑他矫情，结果自己上周改需求时，被盲人实习生小李堵在工位，他举着手机念我写的“userInfoList_v2_final”，念到第三个下划线就卡壳，说“这串符号读着像密码，我得用手指摸三遍才能分清哪个是下划线哪个是数字”。

　　耳机戴久了耳朵疼，我摘了揉半天，突然想起老张那天的原话：“变量名不是给你自己看的，是给所有能接触到代码的人看的——包括用读屏软件的，包括色弱的，包括刚学编程的新人。”我原以为这属于“政治正确”的范畴，结果小李给我看他的屏幕朗读器日志：读到“a1”和“a_1”时，软件会分别念“字母a数字1”和“字母a下划线数字1”，但“a__1”就变成“字母a下划线下划线数字1”，中间没有停顿，他得反复倒带才能确认有几个下划线。更绝的是“btnSubmit”和“submitBtn”，前者读作“按钮提交”，后者读作“提交按钮”，语义完全反了——他说这就像打游戏时，队友喊“上上上”和“上路上路”，差一个字就能让人送人头。

　　外卖送到了，我边开门边听他继续说：“你们明眼人看代码，眼睛扫过去就知道‘userList’是用户列表，‘listUser’可能是个函数名；但我们得靠读屏器的语调——名词在前还是动词在前，重音落在哪，甚至变量名长度（太长的会被截断）来猜意思。”他掏出手机给我看他的代码编辑器，所有变量名都用驼峰式，但下划线全被替换成了“dot”缩写（比如“user.name”），因为读屏器读下划线时会停顿，而“dot”会连读成“dotname”，反而更流畅。我段位其实不高，但那一刻突然意识到：我们平时骂的“烂命名”，对视障开发者来说可能是“无法通关的副本”。

　　键盘有个键声音跟别的不一样，我敲代码时总下意识避开它，结果小李说：“你们明眼人靠视觉区分变量，我们靠听觉——比如‘activeUser’和‘userActive’，读屏器念出来音调不同，前者是‘活跃用户’，后者像‘用户激活’，但你们可能觉得都一样。”他调出一段代码，指着“fetchDataFromServer”和“getServerData”说：“这两个函数名，你们看长度差不多，但我们听节奏——前者是‘获取-数据-从-服务器’，四拍；后者是‘获取-服务器-数据’，三拍。读屏器语速快的时候，三拍的更不容易漏听。”我突然想起上周改需求，把“calculateTotalPrice”改成“calcTotalPrice”，自以为简洁，结果小李说：“‘calc’读作‘calc’，‘calculate’读作‘calculate’，前者太短，读屏器容易吞音，我得反复确认是不是‘cap’或者‘cat’。”

文章配图，仅供参考

　　我原以为这些是“小众需求”，结果小李给我看他们的代码仓库统计：采用视障友好命名的项目，缺陷率比普通项目低30%——因为变量名语义清晰，新人接手时出错少；读屏器能准确朗读，调试时定位问题更快；甚至色弱开发者看代码时，也能通过变量名推断逻辑，不用依赖颜色区分。他说这就像游戏里的“无障碍模式”，不是给所有人开的，但开了的人打得更顺，没开的人也不受影响——“你们明眼人用驼峰式还是下划线式，吵了十年没结果，但视障友好命名是‘优胜劣汰’的产物——谁更易读、易听、易维护，谁就活下来。”

　　充电线不够长，我歪着坐继续问：“那你们内部有命名规范吗？”小李点头：“有，比如禁止用单个字母（除了循环变量），禁止用缩写（除非是行业通用词），禁止用下划线（用驼峰式），禁止用数字下标（用‘first’‘second’）……”他翻出文档，我扫了一眼，发现和我们公司的规范重叠了80%——原来我们吵了半年的“该用‘getUserInfo’还是‘fetchUserData’”，在视障友好命名里早有答案：前者是“获取-用户-信息”，后者是“获取-用户-数据”，语义更明确，读屏器念起来也更流畅。我突然想起老张那天的总结：“代码是给人看的，不是给机器看的——机器只认语法，人得认语义。”当时觉得是废话，现在才懂，这里的“人”，包括所有能接触到代码的人。

（编辑：站长网）

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