# 缩写、简写的优缺点 * Google Docs 版： https://bit.ly/2JgaQCL * GitHub 讨论区： https://bit.ly/321ResR --- 在「刷 LeetCode 练习命名」（ https://bit.ly/2GIyLtk ）时，我观察到 LeetCode 提供的程式码样板经常使用简写与缩写；例如，以下案例中，用 `nums` 代表 `numbers`; 用 `J` 代表宝石（ jewel ）；用 `S` 代表石头（ stone ）。 ```C# // https://leetcode.com/problems/running-sum-of-1d-array/ public int[] RunningSum(int[] nums) ``` ```C# // https://leetcode.com/problems/jewels-and-stones/ public int NumJewelsInStones(string J, string S) ``` 在这系列文章的讨论中，也有网友提过「用 `qty`, `cnt` 代表 quantity, count 」 的主张。 这让我很好奇，有没有什麽方法可以更全面、一致地评量「缩写、简写的优缺点」？ 我试着从以下角度切入： 「每个生态圈、社群、团队、专案多半会有约定成俗的命名风格」；例如， * 游戏业人士可能会用 `hp` 代表耐久力（ hit points ）。 * 工业界人士可能会用 `hp` 代表马力（ horse power ）。 这个「约定成俗」的过程可说是「『知觉负载』成本效益取舍」的演化过程。 ## 知觉负载 所谓「知觉负载（ cognitive load ）」是指「某件事的『难度』」，也就是 「该件事有多耗脑力（工作记忆资源）」；它从三个层面来分析「难度」： * 一件事本质（ intrinsic ）上有多难。 * 例如，「算 2+2 」与「算微分方程式」的难度不同。 * 外部（ extraneous ）因素对一件事的难度的影响 * 例如，同样的知识，对母语是中文的我们来说，「用中文吸收」与 「用英文吸收」的难度不同。 * 个人将一件事（的原理）真正搞懂（内化）有多难。 * 例如，「知道」与「做到」的难度不同。 参考资料： https://en.wikipedia.org/wiki/Cognitive_load ## `num`, `qty`, `cnt` 从知觉负载的角度来看，「理解 `num`, `qty`, `cnt` 这些符号」本质上并不难， 但问题是不同生态圈、社群、团队、专案的人经历过的「约定成俗／「知觉负载成 本效益取舍」演化过程」也不同，就像是游戏业人士、工业界人士对 `hp` 最直觉 （知觉负载成本最低）的联想也不同。 是故，与其论述「缩写、简写的优缺点」，我更倾向去思考「缩写、简写会如何影 响谁的知觉负载成本效益」。 易言之，与其论述「在程式码中使用缩写、简写」是简洁（ brevity ）还是 隐晦（ obscurity ），我会去想「这份程式码是为了什麽而要给谁看？这些人有 什麽样的共同记忆？」，来决定要用什麽样的语言来沟通。 --- 感谢参与 https://github.com/EngTW/English-for-Programmers/issues/7 讨论 的网友。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 136.56.13.184 (美国) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1606463173.A.5E7.html 谢谢 :) ※ 编辑: AmosYang (136.56.13.184 美国), 11/27/2020 15:59:36 谢谢 :) ※ 编辑: AmosYang (136.56.13.184 美国), 11/28/2020 01:14:05