你可曾想象过, 写代码时无需记英文单词, 仅用中文便能完成一整套脚本? 在版本里, 此事真的能够达成。我们能用中文直接定义变量名称, 程序可以正常识别且完整运行, 无需进行额外的特殊设置。
不少初知晓此特征的新手会深感颇为惊喜, 觉着编程门槛刹那间降低许多, 无需费尽脑力去记英文词汇, 能用母语来编写代码。然而在此要郑重告知所有上班族: 此功能仅适宜当作私下的趣味试验, 绝对不可在正式工作脚本里运用。
为何语法准许运行, 工作场景却极为不推荐呢? 其一乃是编码兼容隐患引起的。在不同操作系统, 不同版本办公环境中,Mac的中文编码格式有时会存有差异。你电脑可正常运行的脚本, 复制到同事办公电脑上, 就或许会直接报错, 致使整个自动化脚本完全罢工。在办公场景里, 脚本稳定性始终是首要的, 我们绝不能冒这种影响工作进度的风险, 得谨慎对待。
其次, 整个生态是全部基于英文构建的, 各类第三方库也是如此。网上近乎所有教程, 全部采用英文命名习惯, 案例同样如此, 问题解答亦是这般。要是你习惯运用中文命名, 后续当遇到bug想要去上网寻觅解决办法时, 就很难找到相匹配的参考案例, 排查问题的困难程度会大幅度增加。一旦脚本出现问题, 就会消耗大量额外的时间以进行调试。
职场中自动化脚本会流转给其他同事阅读, 这存在团队协作的现实问题, 还要进行维护、修改。行业内所有人习惯英文代码写法, 若脚本里有大量中文命名, 会极大提升其他人阅读脚本的成本, 也会提升修改脚本的成本。同事接手你的脚本, 还得花时间适应中文命名, 这会给团队带来不必要的负担。
也有些人会这样认为, 自身所撰写的脚本只是供自己使用, 并不会发送给他人, 所以使用中文并无不妥。然而, 我们所编写的用于办公的脚本, 通常会被反复运用数月乃至一两年之久。间隔两三个月后, 当你再次查看那些皆是中文命名的代码时, 一旦出现报错情况, 而去网上搜寻问题的解决方案, 却很难找到与之对应的解决办法。时间一长只会给自己增添麻烦。
并且, 用中文去编写代码仅仅是一项具备趣味性的语言特性罢了, 它比较适宜在个人私下的场合里去耍一耍, 进而体会语言所蕴含的那种趣味。然而, 当真正着手去编写处理报表、整理文件的办公脚本之时, 仍旧得规规矩矩地采用英文。千万绝对不要只是为了贪图新奇, 从而给后续的工作埋下潜藏的隐患。