大家好，我是校长。
前几天，看到这么一个问题，感觉很有意思。
看到这个问题，让我想起来了一个案例。
案例当中的做法不是删除注释，而是更改了所有项目的注释。
案例故事是这样的：
近日，一位叫托马斯的读者向大家分享了一则发生在 1970 年代的故事：一个前同事离职前一顿骚操作、导致他莫名被 “坑” 的故事。
在上个世纪 70 年代，各种繁杂的工具库还未出现，程序员需要遵守的开发思路很简单：优化，提高资源利用率。当时的托马斯还是一名初出茅庐的程序员，有幸被招聘进了一家咨询公司，接手一位前同事的工作 —— 托马斯对这位前同事的形容是：一个非常聪明也十分讨厌的 “混蛋”（以下简称这位前同事为 “HD”）。
平心而论，在托马斯看来 HD 被公司辞退其实有些 “冤”：
公司经理们对项目难度缺乏正确认知，给 HD 设定了一个根本无法实现的最后期限。但 HD 还是坚持下来了，甚至为了完成项目代码，他每周工作时长在 100 小时以上。然而，公司管理层因其产生的加班费感到不满，并由此拒绝了 HD 的加班申请。结果可想而知：HD 与公司管理层产生了巨大分歧，大吵一架后，公司决定解雇 HD。
但问题在于，公司还给了 HD 一个月时间，要求他完成当前项目的代码再走。可试问：在这种辞退理由下，HD 会心甘情愿、老老实实做完这一个月吗？答案是否定的，HD 果然做了一些 “小动作”：他更改了代码中的所有注释。
乍听之下这好像这不是什么大问题，可你要知道，这个举动发生在 1970 年代：在那个年代，高级编程语言还未兴起，
公司所有项目代码均由汇编语言编写，而不是没有原因的 —— 在托马斯看来，如果没有深入研究过，汇编语言的晦涩难懂无异于机器语言。这也就是托马斯认为 HD “非常聪明也十分讨厌” 的原因：项目代码本身没问题，运行情况也良好，可对于下一个接手项目的人来说，早已与实际功能不符的代码注释就是 “地雷”。后来，这颗 “雷” 不幸地误伤到了倒霉的托马斯：“我接手了 HD 的项目，第一个任务是在 HD 的代码中添加更多功能。
结果当然失败了，因为我查看了代码注释。” 尽管将问题汇报至管理层，托马斯却并未获得有效回应，而他担心他也会被因此辞退，又接连进行了几次检查，最终得出结论：
代码注释果然是在胡说八道。可惜，就算明白了问题所在，当时整个公司也没人能弄清楚代码的哪些部分做了什么，所以最后只能删除所有注释，再将其黑盒化。
据托马斯表示，一年之后他就离开了这个项目，但黑盒代码此后还运行了五年，直到一家新的咨询公司接管了它：“即使如今，这些代码可能仍在某个地方运行，毕竟黑盒代码像蟑螂一般顽强。”
到这里故事基本上结束了。
看到了吗？这个故事是发生在 1970 年，当时对注释动了手脚，是没问题的，也不会被发现，即使被发现也没用。
因为根据当时的条件，有两个因素导致对代码注释动手脚是成立的：
1、没有代码管理工具；
2、当时的代码是汇编，属于低级编程语言，晦涩难懂。
没有代码管理工具，公司就无法证明同事 HD 对代码动了手脚；低级编程语言晦涩难懂，对注释动了手脚之后，很难理解，恢复并搞懂很难，所以，只能将其黑盒化了。
但是，现在则不同了，随机技术的发展。对代码注释动手脚的两个因素都被破除了。
1、我们现在拥有了代码管理工具，你对注释动了手脚，也可以会滚，而且很容易查到你是故意为之的，这时候，对注释动手脚也属于破坏代码的一部分，虽然系统能够正常运行，但是，还是破坏了代码，公司要告你，也极有可能成立。
2、假设你对注释动了手脚，删除了注释，甚至混淆了注释，但是，现在大多数编程语言都是高级语言，搞懂比较容易，虽然可能会费点时间，但是，恢复起来并不是想象中的那么难。
综合下来，我想说：程序员离职删光代码注释是否违法，我不知道，但是，毫无意义，有点掩耳盗铃的意思。
