代码即注释，注释即代码的概念是如何形成的

"代码即注释，注释即代码"这个概念是如何形成的呢?记得之前看一些讨论，程序员应该如何写代码的注释，大家的意见很多，不过我只对两句话记忆非常深刻：

(代码)既然难写，就应难读。

代码本身就是注释。

根据这两句话意见呢，我们的代码本身并不需要太多的注释内容。而应该尽可能的通过合理的模块与函数划分、明确的信号命名、清晰的逻辑表达来替代繁琐的注释说明，同时再借助比较完备的文档进行代码的传接。更何况呢坊间一直有一句传闻：代码易，人可替(我刚编的哈哈哈)，所以久而久之我就养成了不写注释的好习惯。

俗话说，程序员都有两个最大的厌恶：一是别人不写注释，二是别人让自己写注释。我估摸着哈，这都是和我一样养成好习惯的盆友。不过不写注释偶尔也会带来一些恶果，最典型的就是隔一个月半个月要改自己的祖传代码时，得把代码从头理一遍的痛苦。当然，代码即注释这句话不是本文的重点，重点是后面的注释即代码。

注释即代码的思想是怎么来的呢?来自于两个对本夺命脚本师影响颇深的事情。一件是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个，以后再慢慢增加吧。

审核编辑：汤梓红