大家对于中文变量名是如何看待的？

[FakeLeung]

恕我愚昧，实在是不想翻译各种奇怪的名称了，直接用中文当作变量名简洁明了（对于我来说）

不知道大家如何看待中文变量名的？

[xuanwu]

@blankme #246 说曹操曹操到。搜狗输入 5.5.1.9856 已经支持指定 app 下”中文输入下使用英文标点“。不用在 vscode 和浏览器之间来回设置输入法咯（搜狗开发组很贴心哈）：

[FrankHB]

@myfei 那首先说明你输入效率太低。
输入不会成为瓶颈的情况下拿轮得到补全的 UI 反应？而且要是刚好 le 和 leader 之间还有其它变量名你不能马上回车怎么办？就算恰巧能回车，非连续输入的情况下不确信是不是马上能回车还得愣一下不需要时间？信不信你输入 le 去选词的时间都够我敲两个 leader 或者“领导者”了？
而更大的槽点是你没搞清主要问题在哪。正常输入代码实际上多花几倍时间输入 leader 或者领导者都不会成为瓶颈，因为这种低级操作很容易形成“肌肉记忆”，在瞬时是可并发的，原则上不需要阻碍思路。而停下来思考要不要回车甚至看 UI 反馈选字是复杂的分支操作，基本没法并发，明显更打断思路影响效率。
另外，真的不得不打断思路去对付一个比较长的名称的话，我倾向选择选中复制粘贴，因为可以减少让具体拼写（尤其是意义不明的前缀）过大脑污染 cache 的机会，避免之后稀里糊涂念歪变量名而被迫停下来修正这样再次增加打断思路的风险。

[myfei]

@FrankHB 看到肌肉记忆我就笑了，写代码是让你打字呢，还肌肉记忆。别的不说，解析一个 json 要用到多个甚至数十个变量，用的时候，也是多个变量赋值，使用，计算，全部都要仔细看清楚，才避免出错。写代码让你比谁打字快呢？
还够你两遍打出 leader，那是这个单词简单，若是有大小写再加上驼峰多个组合的变量名呢，你也要自己重打一遍？用 IDE 提示回车选择，还有另一个重要原因，就是避免出错。
还回车看 UI 反馈，没法并发？写代码明明是个同步操作，等这个结束了再往下进行下一步，是个连贯操作，那里影响效率了？

[no1xsyzy]

@myfei 你要知道
#define if if(
#define then )
#define begin {
#define end }
是啥意思，你就知道写代码时肌肉记忆是什么了。

> 写代码明明是个同步操作
你就是那个全身上下只有一根神经走串行协议的人？

[no1xsyzy]

@JasonTsang > 定义变量和一些语法逻辑你却不能使用中文
推荐 Racket （

[snowonion]

给个适合中文变量名的例子。不在字符串和注释里的中文都是函数名和形参（ actually，模式）名。

https://gist.github.com/SnowOnion/3774f0b8dbd6357541dca350297e8903

[mingl0280]

@no1xsyzy 您就是两个键盘同时打的并行带师？

[no1xsyzy]

@mingl0280 我至少有两只手，并且还有鼠标

另外，试问哪个代码编辑器 /IDE 会没有 “同时开多个文件” 的功能？
又有哪个代码编辑器 /IDE 没有双文件分屏功能？
那些不能开多文件不能分屏的代码编辑器现在死光了没？
就算是以轻量著称的 Notepad++ 都有这两个功能，由此看来世界上几乎所有程序员都是并行的。

继续延伸，甚至连 “传话筒” 都是双屏。
尽管他们的工作不过是将系统中出现的一些工单打电话派给现场人员，但他们也是并行的。

如果你想继续，那么我还可以继续延伸。

我不是什么大师，我是约 70 亿并行人之中的平凡一员。

只要你读过相对论，即使是简单瞄过《时间简史》，你都应该知道这个世界上不存在真正的同步，所有同步都是幻象。
其中大部分是将 “串行” 当作 “同步”，少部分是将 “一致” 当作 “同步”。

意识串行并不代表你的整个大脑都运作在串行模式下。类似地，“Python 存在 GIL 锁” 不等于 “Python 不能多线程” 或者 “Python 多线程没有用”，你可以让一些线程做内核级阻塞操作，比如网络，同时其他线程进行计算。

但写代码肯定不是串行的，除非你的大脑根本没有适应，以一种低效的方式去模拟它。“编程” 不是你的 “知识”，对你而言那不过是一些关于 “如何编写程序” 的 “信息”，而不是 “如何设计程序” 的 “知识”，更不是 “如何发生计算” 的 “智慧”。（参考 DIKW 理论）
任何 “知识” 的使用，都是并行的。
知识图谱正是知识的组织结构的真实反馈。一个点的触发即会导致其相关的知识被触发，而像波浪一样扩散开去。

[no1xsyzy]

@myfei 另外，如果哪个 JSON 解析器不能让你用 IDE 补全、不能静态解析的话，该换了。
不考虑目前具体的生态的话，就算是 C 也可以进行补全。汇编有点难度，操作上也不甚方便，但也不是不行，至少可以静态解析检查的。
JSON 不是图灵完备的。

[FrankHB]

@myfei 生理上“写代码”就不可能是完全同步的操作。你所谓的同步，是逻辑步骤之间的顺序性，这不影响身体的不同部位能够并行，自然有条件并发。
如果你非得把注意力来回集中在手上，那手动一下每次同步都有几个毫秒的神经传递延迟，加起来是不是至少有一半时间你脑子都不用干活了？况且正常人不刻意做根本做不到这种严格的同步。
退一步讲，不严格的“全神贯注”单工操作也是一种低效的方式，因为至少在注意力集中在理解代码的时候，手在物理上也是不必要停下来的。明明能做到（有限地）并发，为什么强行要（假装）顺序操作？
看到你笑了我就知道你不擅长用键盘输入，至少是不擅长大多数人原则上都能学会并的输入方式。像 QWERTY 这样的键盘布局，本来就刻意避免什么固定的含义，因此正常人高速熟练输入之后是没理由时常去盯着刚刚摁过的键位发愣的；结果是对按键词频的感知是无意识的，但又不会立刻全部遗忘。特别地，像 pre-/re-/init-/-tion 之类常见双手左右开弓几乎并行输入的按键组合，输入几乎不过大脑基本上也不会出错。这就是一种肌肉记忆。
写代码当然不需要首先强调输入有多快，但这个快就是指吞吐量；如果影响响应中断思路，那么实际上吞吐量再大也是慢的，这种影响应该越小越好。就算这种情况平时不怎么遇到，在一瞬间成为瓶颈也是不爽的。如果你从来没有这样的体验，恐怕是你没有尝试处理过极限情形，或者你的脑子一向转得太慢而从来不考虑这样做了。
你所谓的不输错，那首先要求是盯着屏幕取词，跟用来输入的动作没有直接关系；真要有关系，那也是输入不需要经常性劳烦大脑，减少打断思路的机会能让注意力集中在这种输入以外的地方，那也能更高效。

[myfei]

@FrankHB 你们回复的时候，都不看前提的吗？
这个问题讨论的是中文变量的问题，我一直也就这个前提在回复。我不知道你说的这些写代码的同步了并发了，还扯出一个什么吞吐量跟这个中文变量名有什么关系。
而且我不知道你一直在提的写代码时生理上的活动，大脑活动，这些东西我不知道你是臆想的还是有研究的，但肯定不属于编程的范畴，这个我真不懂。
再说肌肉记忆，我说变量很难应用肌肉记忆，因为变量要涉及到，赋值，计算等操作，而且变量一般来说会很多，还说了个与服务器交互时一个 JSON 有几十个变量的情况很常见。
结果下面就有人回复我说，你说没肌肉记忆，就给我写了一个宏定义，我就？？？。我说宏定义不能用肌肉记忆了，API 不能用肌肉记忆了？我就说一个变量名不好利用肌肉记忆，就默认我的意思是写代码不用肌肉记忆了？
还有人回复我说"如果哪个 JSON 解析器不能让你用 IDE 补全、不能静态解析的话，该换了。" 我说 JSON 解析的事了？？？我说的是一个 JSON 里有几十个变量，关解析什么事？再者自动解析下来，就看了一眼，根本就没有敲，不就又证明变量形不成肌肉记忆？
最后，讨论归讨论，你若胆感再人身攻击我，我就 CNM。

[FrankHB]

@myfei 麻烦你自己先理顺逻辑。
输入代码和理解应该什么代码能一定程度上并行，这是常识，也是讨论这里的问题的前提之一。这个前提下你说的很多东西本来就都不需要在这里考虑，然而你非得硬放在一起，那只能多说几句了。（而且这不是我一个人的意见。）
另一个前提是你提过的，输入在这里一般不会成为瓶颈。这个结论没问题，我也同意，但按生理常识，严格按你声称的实现方式（同步操作）和这个结论有矛盾。所以我还得多指出你这里的问题。
上面的几个问题和中文不中文变量名是没多大直接关系，但跑题很大程度是你引起的，你得自己绕回来。
生理活动事实上如何，最粗浅的部分你自己就应该能感知得到，验证起来应该不费吹灰之力，我是不懂你能如何不懂或者强行能得出相反的结论。
至于肌肉记忆，我可没说能代替理解。能肌肉记忆的仅限输入过程中的很小的一部分活动，但已经提升了显著的可并行性，因为严格按你说的同步实际上就是极慢的。我提这个是作为结果这应该无关紧要，但是想要排除就是不现实的。
其它工作也不是同等费时的。像选择 API 之类虽然不是肌肉记忆，但熟练起来可以提升的空间很大，和肌肉记忆依赖熟练度倒是有一些类似的地方。对大多数人来讲，真正怎么都慢的是如何设计解决方案这样的没有经验先例可循的业务问题，这不可能靠肌肉记忆或者经验担保效率总是能够提升。而到编码阶段，不熟悉要用的 API 这样的场景才慢，但慢主要是评估确认 API 的活动（包括看文档），也不是选择具体 API 这样的思考。
相比之下，分辨哪个变量是哪个这种问题，比选择 API 和判断效果是否能够达到目的通常更快。你非得把变量名写得奇怪和带有误导性，会让这个活动更麻烦，但也就是麻烦，一般不应该花费更多时间；没法避免这种情况就该考虑撂担子不干了。像你说的几十个变量名里面选择一个这样的情况，除非这是业务逻辑的一部分（比如设计中就要求这么几十个名字里挑东西），也不应该是最慢的一类活动。如果这个已经成为瓶颈，大概是要检讨设计了。

[FrankHB]

另外 @no1xsyzy 说的肌肉记忆和我说的不完全是一回事，那种依赖的视觉反馈的更高级也更难形成，这个和个人习惯也有关系。总体来讲，这比输入上的肌肉记忆更偏向于实现，并不那么人人适用，只是根本原理是一样的。
对我来说，我首先会把阅读代码时的存在的 { 和 } 之类的标点在视觉上垂直对齐这类情况训练成“肌肉记忆”，因为这在确认块对齐的时候非常明显地提升时间效率。这也是我不想看非等宽字体写的代码，以及非常厌恶 {} 强行不对齐的代码风格的原因。
此外，我排斥被动的肌肉记忆：如果能不记忆，那么最好没有。像 begin 这样的记号（而非自然语言意义上的单词）实际上在语法(syntax) 而不是文法(grammar) 上就是固定的，begin 和{的视觉差异是先天显著的，我会在效果上要求我使用的语言有{的直接支持而不愿意去读写 begin 再自己脑补#define begin {这一条记忆规则。自己去形成 begin 映射到{肌肉记忆会浪费记号编码空间和浪费视觉的带宽，更令我更不爽的是其他人写的代码还是写 begin 而使我被迫去做这种无用功的事实——明明是某些人自己没搞清楚 { 比 begin 的普遍特殊在哪而根本不值得让人去 #define，偏偏这些人中的一部分无知者还大言不惭 begin 的所谓“可读性”比 { 更好，也是醉了。这种情况下的被动肌肉记忆实际上体现了输入质量（代码和促使代码这样写的语言设计）的恶劣（所以光是这一点就不喜欢 PASCAL 和 Lua 之流）。相比之下，使用 QWERTY 键盘的肌肉记忆，就算能用别的方案去替代，基本上也就是用另一套肌肉记忆而已，省不掉的，所以就不用这样纠结了。

[no1xsyzy]

@myfei
> 解析一个 json 要用到多个甚至数十个变量，用的时候，也是多个变量赋值，使用，计算，全部都要仔细看清楚，才避免出错。
这个是给 linter 干的事，发现 JSON 键名写错了也应该是 linter 干的事。TypeScript 可以写 Interface。Python 下有 dacite 可以写成 dataclass。我不清楚其他语言内的设施，但 JSON 的处理肯定是转化为相应语言内的 struct-like 数据结构的。
如果你吃过 Windows 下 Chrome 开发人员工具默认 Consolas 字体的亏你再也不会想要去人工检查变量名有没有字母错了。至于 friendly name 之后，输入名字这种事，当然是肌肉记忆了啊。英文的肌肉记忆还不深吗？就算用上 IDE 的补全，很大程度上都会产生肌肉记忆。

[no1xsyzy]

@myfei 就算语言再动态，数据那块都是在主张静态或者半动态（ Union 类型）的数据拓扑。真正的动态数据拓扑到现在没有人有任何实现头绪，如果有头绪的话大概率可以拿图灵奖（结合 Lisp 的程序即数据，那就是自动编程机器）。

[no1xsyzy]

@FrankHB 我见过的 {--} 对齐，只有 Linux Kernel 在这么做……
最近才接触一些过于复杂的 SQL，才发现各种 SQL 格式化工具都不够好，尤其是 WHERE AND 这块和子查询。
人人都背负锁链跳舞，最怕有些人觉得没有，或者像 @myfei 觉得背不背没区别。
“人生来自由，而无往不处于枷锁之中；认为自己是一切的主人的人，比一切更是奴隶。”

[xuanwu]

@FakeLeung 在这个知乎回答借用了截图： https://www.zhihu.com/question/355223335/answer/890175502 如有不妥请告知。发了一段时间之后才火起来，不好意思没提前知会。