Clean Code (2)

guyu_1

Clean Code (2) [Copy link]

Ron Jeffries, author of "Extreme Programming Practice", carefully studied Baker's simple code rules and listed them in order of importance:

＆ Pass all tests

＆ No duplicate code

＆ Embody all the concepts involved in the system

＆ Include as few entities as possible, such as classes, methods, functions, etc.

The fact that it can pass all tests will be explained in detail in the later article in terms of architecture design. Here we still use a small example to illustrate some techniques of "no duplicate code".

Once I printed out several different program codes on A4 paper and spread them flat on my bed for comparison. My daughter who was still in elementary school said to me: Dad, do you just watch these caterpillars crawling around every day? Always, if, else, begin, yes, and end, that's probably it. The childish words made me laugh, and when I looked back at the codes, I suddenly remembered what a master once said: Most programs are made up of very similar elements. It is true! At the same time, due to this similarity, repeated codes appear in many programs. Let's take a look at the following code:

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

This is the code of a serial port sending program. The function it implements is to send three data 0, 1, and 2. Obviously, in lines 2 to 4, it is equivalent to doing the same thing three times in the program. Lines 10 to 19 are also selected three times, which is repeated code. As the number of signals increases, four, five...N are needed. The program becomes more and more cumbersome.

The repeated appearance of the same code makes the boundary of "uniqueness" blurred and confusion is easy to occur. In other words, the author's idea is not implemented in the best way. In this example, if you enter "?" in the search engine, you will get similar results. Remember the "do simple things" mentioned in the previous article? At this time, we should think about whether the code itself is redundant or whether the object has too many functions. If it is the former, we should improve it from effective naming, etc. If it is the latter, then "simplify complex things" and take some means to reconstruct it so that the functions can be clearly explained and implemented.

For the code above, what should be the correct idea and approach? Let's take a look at the following code.

[table=98%] [tr] [td=30]

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

[/td] [td=538]

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

[align =left] else begin

dout <= data[9 -cnt2];

end

end

[/td] [/tr] First, select din0, 1, and 2. If it is se10, then din-se1 is equal to din0; otherwise, if it is se11, then din-se1 is equal to din1; otherwise, din-se1 is equal to din2; Next, we add 0 and 1; Then select the timing. The change of dout is XXXXXX, and the code is completed. By comparison, it is not difficult to see that in the second code, whether it is filling 0 or 1, or sending dout, it is only done once. A line of code only does one thing and does it well. Programming languages seem to exist specifically to solve this problem.

Another point is that in the two examples in this section, the previous code must be verified in turn when verifying, and the signal sent din0, din, din2...din N, any error in this process is very troublesome; the second code only needs to verify that the logical relationship between them is correct. The important thing is that this section uses a very small signal output code as an example. The larger and more complex the code, the greater the efficiency and quality gap between the two methods. Original creation by EEWORLD forum user guyu_1, if you want to reprint or use it for commercial purposes, you must obtain the author's consent and indicate the source

郝旭帅

Top one

懒猫爱飞

Sometimes you trade space for efficiency, and sometimes you sacrifice efficiency for space. There is a little difference between embedded programming and computer APP programming.