"代碼即注釋，注釋即代碼"這個概念是如何形成的呢?記得之前看一些討論，程序員應該如何寫代碼的注釋，大家的意見很多，不過我只對兩句話記憶非常深刻：

(代碼)既然難寫，就應難讀。

代碼本身就是注釋。

根據這兩句話意見呢，我們的代碼本身并不需要太多的注釋內容。而應該盡可能的通過合理的模塊與函數劃分、明確的信號命名、清晰的邏輯表達來替代繁瑣的注釋說明，同時再借助比較完備的文檔進行代碼的傳接。更何況呢坊間一直有一句傳聞：代碼易，人可替(我剛編的哈哈哈)，所以久而久之我就養成了不寫注釋的好習慣。

俗話說，程序員都有兩個最大的厭惡：一是別人不寫注釋，二是別人讓自己寫注釋。我估摸著哈，這都是和我一樣養成好習慣的盆友。不過不寫注釋偶爾也會帶來一些惡果，最典型的就是隔一個月半個月要改自己的祖傳代碼時，得把代碼從頭理一遍的痛苦。當然，代碼即注釋這句話不是本文的重點，重點是后面的注釋即代碼。

注釋即代碼的思想是怎么來的呢?來自于兩個對本奪命腳本師影響頗深的事情。一件是verilog-mode的使用，這個工具的介入直接讓困擾我多年的模塊例化與互連問題迎刃而解;另一件是前司開發的RTL檢查工具，借助注釋生成的檢查代碼節約了驗證大量的時間，因為我自己是驗證所以對此感受還是頗深的。腳本的目的無非是兩個，提高效率與提高質量，而以注釋生成代碼以小生多的思路，不僅大大的提升了工作的效率，也能夠保證生成代碼的高質量，畢竟人會出錯工具不會出錯(除非是我自己和工具沖突了，此時必是工具有bug╭(╯^╰)╮)。

那么在樹立了注釋即代碼的思想后，我就沿著這個方向進行了幾個腳本的開發。

第一個是名叫gen_link的腳本，看這個名字就知道這是模仿verilog-mode中的自動連線功能而開發的RTL例化與互連工具。為什么會重復造輪子呢?說來就比較曲折了，因為我不知道verilog-mode是開源的工具￣□￣||知道了這件事之后，我就轉而去研究了如何配置和使用該工具了，甚至還做了專欄。

第二個腳本是auto_assert，這個腳本和前司的借助注釋檢查代碼的工具思路是一致的，不過我在其中做了簡化和一些功能的補充。最終完成的腳本能夠支持如下的功能：

1.信號的不定態檢查

2.信號在使能時的不定態檢查

3.仿真過程中信號的取值檢查

4.仿真過程中使能時信號的取值檢查

5.仿真過程中信號取值覆蓋率分析

6.仿真結束時信號結束值檢查

然后我就發現了這個腳本的致命問題：這玩意會極大地增加設計的工作量!因為這個致命問題的存在，后面雖然我還對其進行了維護，但是一般不會在工作中使用了，就算用也只用最基礎的不定態檢查和結束值檢查功能。

第三個腳本是auto_unfold，這個腳本的功能是對代碼中的相似代碼進行循環展開，比如下面這種：

本來呢我以為這個是verilog-mode中的原生功能，后來才發現是前司內部自己開發的派生功能。然后我又沒有對其進行進一步開發的能力，那能怎么辦呢?只好借助python開發新的腳本然后嵌入到vim中了。

最后一個腳本是auto_dff，這個腳本我前幾天才寫好的，寫它的目的是啥呢?在前面的文章提到了dff例化風格代碼，在實踐的過程中就會發現一個問題，那就是每一個寄存器的例化和信號聲明寫起來也是挺煩的。在某一個進行進行批量寄存器替換的夜晚，我突然感覺寫這么多無效的寄存器代碼也非常的不能忍，所以開發了這個腳本：

但是說來非常的慚愧，寫完這個腳本后我就很久沒有開發代碼了，一直沒能好好的感受下效率提升的效果。

目前為止遵循“代碼即注釋，數值即代碼”思路開發的腳本就是這4個，以后再慢慢增加吧。

審核編輯：湯梓紅