大家好，我是校長。

前幾天，看到這么一個問題，感覺很有意思。

看到這個問題，讓我想起來了一個案例。

案例當中的做法不是刪除注釋，而是更改了所有項目的注釋。

案例故事是這樣的：

近日，一位叫托馬斯的讀者向大家分享了一則發生在 1970 年代的故事：一個前同事離職前一頓騷操作、導致他莫名被 “坑” 的故事。

在上個世紀 70 年代，各種繁雜的工具庫還未出現，程序員需要遵守的開發思路很簡單：優化，提高資源利用率。當時的托馬斯還是一名初出茅廬的程序員，有幸被招聘進了一家咨詢公司，接手一位前同事的工作 —— 托馬斯對這位前同事的形容是：一個非常聰明也十分討厭的 “混蛋”（以下簡稱這位前同事為 “HD”）。

平心而論，在托馬斯看來 HD 被公司辭退其實有些 “冤”：

公司經理們對項目難度缺乏正確認知，給 HD 設定了一個根本無法實現的最后期限。但 HD 還是堅持下來了，甚至為了完成項目代碼，他每周工作時長在 100 小時以上。然而，公司管理層因其產生的加班費感到不滿，并由此拒絕了 HD 的加班申請。結果可想而知：HD 與公司管理層產生了巨大分歧，大吵一架后，公司決定解雇 HD。

但問題在于，公司還給了 HD 一個月時間，要求他完成當前項目的代碼再走。可試問：在這種辭退理由下，HD 會心甘情愿、老老實實做完這一個月嗎？答案是否定的，HD 果然做了一些 “小動作”：他更改了代碼中的所有注釋。

乍聽之下這好像這不是什么大問題，可你要知道，這個舉動發生在 1970 年代：在那個年代，高級編程語言還未興起，

公司所有項目代碼均由匯編語言編寫，而不是沒有原因的 —— 在托馬斯看來，如果沒有深入研究過，匯編語言的晦澀難懂無異于機器語言。這也就是托馬斯認為 HD “非常聰明也十分討厭” 的原因：項目代碼本身沒問題，運行情況也良好，可對于下一個接手項目的人來說，早已與實際功能不符的代碼注釋就是 “地雷”。后來，這顆 “雷” 不幸地誤傷到了倒霉的托馬斯：“我接手了 HD 的項目，第一個任務是在 HD 的代碼中添加更多功能。

結果當然失敗了，因為我查看了代碼注釋?！?盡管將問題匯報至管理層，托馬斯卻并未獲得有效回應，而他擔心他也會被因此辭退，又接連進行了幾次檢查，最終得出結論：

代碼注釋果然是在胡說八道?？上В退忝靼琢藛栴}所在，當時整個公司也沒人能弄清楚代碼的哪些部分做了什么，所以最后只能刪除所有注釋，再將其黑盒化。

據托馬斯表示，一年之后他就離開了這個項目，但黑盒代碼此后還運行了五年，直到一家新的咨詢公司接管了它：“即使如今，這些代碼可能仍在某個地方運行，畢竟黑盒代碼像蟑螂一般頑強。”

到這里故事基本上結束了。

看到了嗎？這個故事是發生在 1970 年，當時對注釋動了手腳，是沒問題的，也不會被發現，即使被發現也沒用。

因為根據當時的條件，有兩個因素導致對代碼注釋動手腳是成立的：

1、沒有代碼管理工具；

2、當時的代碼是匯編，屬于低級編程語言，晦澀難懂。

沒有代碼管理工具，公司就無法證明同事 HD 對代碼動了手腳；低級編程語言晦澀難懂，對注釋動了手腳之后，很難理解，恢復并搞懂很難，所以，只能將其黑盒化了。

但是，現在則不同了，隨機技術的發展。對代碼注釋動手腳的兩個因素都被破除了。

1、我們現在擁有了代碼管理工具，你對注釋動了手腳，也可以會滾，而且很容易查到你是故意為之的，這時候，對注釋動手腳也屬于破壞代碼的一部分，雖然系統能夠正常運行，但是，還是破壞了代碼，公司要告你，也極有可能成立。

2、假設你對注釋動了手腳，刪除了注釋，甚至混淆了注釋，但是，現在大多數編程語言都是高級語言，搞懂比較容易，雖然可能會費點時間，但是，恢復起來并不是想象中的那么難。

綜合下來，我想說：程序員離職刪光代碼注釋是否違法，我不知道，但是，毫無意義，有點掩耳盜鈴的意思。