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

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

代碼本身就是注釋。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：湯梓紅