无障碍编程：变量命名如何无声包容视障开发者

　　跟开发吵了一架，就因为变量名的事儿——他们非说“userInfo”比“user_info”更“现代”，我原以为这不过是代码风格之争，结果上周视障同事小周找我吐槽，说他们组的代码他读着费劲，我才反应过来，这他妈哪是风格问题，这是无障碍编程的坑啊。

　　小周用的是屏幕阅读器，这玩意儿读代码全靠变量名的发音和结构。他说“userInfo”读出来是“用户信息”（中文翻译），但中间没空格，阅读器不会停顿，连着念快了就跟“用户信”似的，有时候他得反复听两遍才能确定是不是四个字。更坑的是，有些变量名是缩写，比如“userAuthInfo”，阅读器直接念“用户认证信息”，可要是写成“user_auth_info”，阅读器会在每个下划线后停顿，他就能听出“用户-认证-信息”三个部分，理解起来快多了。

　　风扇一直在转，嗡嗡的，我听着都烦，更别说小周了——他得靠听觉抓代码逻辑，稍微有点干扰就容易漏细节。我原以为这不过是少数人的需求，结果查了下资料，发现视障开发者在程序员里占比不低，而且他们用的工具（比如屏幕阅读器）对变量名的处理方式，和咱们看代码的逻辑完全不一样。咱们觉得“驼峰命名法”更优雅，可对他们来说，下划线才是“无障碍友好”的标配。

　　开发那边不乐意了，说“下划线丑”“不符合行业惯例”。我直接甩了份数据——他们组最近重构的模块，视障同事小周的代码审查通过率比其他人低三成，原因全是变量名歧义。比如有个变量叫“orderStatus”，阅读器念“订单状态”，可代码里实际存的是“已取消/已发货”这种枚举值，小周听的时候总以为是个布尔值，结果调试了半天才发现问题。要是写成“order_status”，阅读器停顿更清晰，他早就发现不对劲了。

　　跟领导汇报这事儿的时候，窗外天都黑了，外卖凉了我也没顾上吃。领导倒是挺开明，说“优胜劣汰嘛，能提升效率的命名方式就该推广”。我原以为他会纠结“代码规范统一”，结果他直接拍板：下季度代码审查加一条——变量名必须同时支持驼峰和下划线两种风格，新代码优先用下划线，老代码逐步重构。开发那边炸锅了，说“这会增加维护成本”，我直接怼回去：“你们觉得多敲个下划线麻烦，可小周他们得花三倍时间听代码，这成本谁算过？”

　　其实这事儿让我想起之前搞备份策略的时候——业务方非要实时同步，结果主从延迟把慢查询都爆出来了，最后还是得回归到异步备份。变量命名也一样，所谓的“行业惯例”未必适合所有人，尤其是视障开发者这种被主流忽视的群体。我查过不少资料，发现国外有些团队早就开始推广“无障碍命名规范”，比如变量名里避免用缩写（除非是行业通用缩写）、优先用下划线分隔、注释里明确变量用途——这些细节看着小，可对屏幕阅读器来说，差一个下划线可能就多听两遍才能理解。

　　跟开发吵完那架的第二天，小周路过我工位，问了句“好了没”——他指的是变量名规范的事。我点头说“在推了”，他笑了笑，说“谢谢啊，以前读代码总像在听绕口令，现在至少能听出层次了”。那一刻我突然觉得，这他妈才叫“技术温度”——不是堆多少高并发、搞多少分布式，而是让每个开发者，不管看得见看不见，都能顺畅地写代码、读代码、改代码。

　　当然，我也知道这事儿有局限——比如有些旧系统没法改变量名，或者某些框架强制要求驼峰命名。但至少新代码可以优化，审查流程可以加无障碍检查，开发培训可以加屏幕阅读器使用演示。优胜劣汰嘛，能活下来的命名方式，一定是既让明眼人舒服，也让视障开发者无障碍的——就像慢查询优化，最终受益的是整个系统的稳定性，而不是某个人的偏好。

文章配图，仅供参考

（编辑：站长网）

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