《极限编程实施》作者Ron Jeffries 仔细研究了贝克的简单代码规则,并依其重要顺序分别列为:
&能通过所有测试
&没有重复代码
&体现系统中的全部涉及理念
&包括尽量少的实体,比如类、方法、函数等
能通过所有测试这一点,后文中在架构设计方面详细说明,这里我们还是借助一个小的例子说明“没有重复代码”的一些技巧。
曾经有一次我将多份不同的程序代码用A4纸打印出来,平摊到我的床上对照时,还在上小学的女儿在旁边说道:爸比,你每天就是看这几只毛毛虫爬来爬去吗?always、if、else,begin,对了,还有end,大概就是这几只。小孩子幼稚的话语引得我哈哈大笑,当我回头看向这些代码时,突然记起一位大师说过的话:大部分程序都是由极为相似的元素构成。诚哉斯言!同时,由于这种相似性,许多程序中出现了重复的代码。我们来看一下下面这组代码:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
assign data0 = {1'b1,din0,1'b0};
assign data1 = {1'b1,din1,1'b0};
assign data2 = {1'b1,din2,1'b0};
always @(posedge clk or negedge rst_n)begin
if(rst_n==1'b0)begin
dout <= 0 ;
end
else if(sel0)begin
dout <= data0[9-cnt2];
end
else if(sel1)begin
dout <= data1[9-cnt2];
end
else begin
dout <= data2[9-cnt2];
end
end
|
这是一个串口发送程序的代码,所实现的功能是发送0、1、2三个数据。很明显,在第2到第4行中,相当于程序中同样的事情做了三遍。第10到第19行也是选了三次,这就属于重复的代码。随着信号越来越多,就需要不断的四个、五个……N个。程序越来越累赘。
同一段代码的反复出现,“唯一性”的边界变得模糊,也容易出现混乱。或者说,作者的想法没有得到最佳的实现。在本例中假设通过搜索引擎输入“
?”就会得到相似的
?
个结果。还记得前文中提到的“做简单的事”吗,这时我们应该思考是代码自身赘余还是对象功能是否太多。如果是前者,应该从有效命名等去改善它;如果是后者,那就“把复杂的事情简单化”,采取某种手段重构它,使功能可以清晰的被说明以及被实现。
如上面的代码,正确的思路和做法应该是什么呢?我们来看下面这份代码。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
always @(*)begin
if(sel0)
din_sel = din0 ;
else if(sel1)
din_sel = din1 ;
else
din_sel = din2 ;
end
assign data = {1'b1,din_sel,1'b0};
always @(posedge clk or negedge rst_n)begin
if(rst_n==1'b0)begin
dout <= 0 ;
end
else begin
dout <= data[9-cnt2];
end
end
|
首先先把din0,1,2选出来,如果se10的情况下,那么din-se1等于din0;否则,在se11的情况下,那么din-se1等于din1;否则,din-se1等于din2;
接下来我们再来补充0和1;
接着选择时序。dout的变化为XXXXXX
,到此代码完成。
通过比较不难看出,第二份代码中,无论是补0补1,还是dout送出,都只做一次,一行代码只做一件事且做好这件事,让编程语言看起来像是专为解决这个问题而存在的。
还有一点,在本节的两个例子中,验证时前一份代码要依次验证,送出的信号din0,din,din2……din N,这个过程中任何一点出现错误都非常麻烦;而第二份代码仅需要验证它们之间的逻辑关系正确即可。
需要注意的是,本节是以一个非常小的信号输出代码为例。越是大型的、复杂的代码,这两种方法之间的效率和质量差距越大。下一节《信号命名和定义应该明确》
|