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

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

代碼本身就是注釋。

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

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

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

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

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

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

1.信號的不定態(tài)檢查

2.信號在使能時的不定態(tài)檢查

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

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

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

6.仿真結(jié)束時信號結(jié)束值檢查

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

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

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

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

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

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

審核編輯：湯梓紅