Let you know software development in advance (45): The first impression of the Code

Part 1 software R & D work summary

First impression of code

 

We all pay attention to the first impression on others, and there are many books that teach us how to make a good impression on others. Indeed, if we see a person at the first glance, we will feel uncomfortable, so we will be psychologically resistant. We will feel a sense of alienation when we see him again later. Because of this, face engineering is very important in today's social interactions. In any case, let's talk about it first.

The same is true for the code, which may also give a good or bad impression to others. When we see beautiful code, we will have a desire to continue researching, and even a feeling of enjoyment. On the contrary, when we see ugly code, we will bite our teeth, because it is not only not conducive to reading, but also waste a lot of time, reducing the efficiency of our work. Everyone wants to write good code, just as everyone wants to get a good result in the exam. However, in our actual work, there are many factors that make us feel helpless and want to do things well, but the result is counterproductive.

Generally, the Code gives us the following first impressions:

Typographical neat vs typographical not neat

When we open a code file, what we first see is how it is typeset, which is also the most intuitive feeling. When code formatting is neat, we can easily find out its logic and logic, and quickly understand what functions it actually wants to implement. When the formatting is not neat, our eyes will feel tired, this affects our thinking.

The formatting code is as follows:

 Code snippet

Code segment B

Code snippet C

Code segment D

 

The code format is as follows:

Code snippet

Code segment B

Code snippet C

Code segment D

 

Naming Conventions vs naming irregularities

After reading the layout, we will see the name of each function and variable. Generally, projects have a large number of lines of code, so it is impossible for us to spend a lot of time understanding what each function and variable is intended for and what it is. This requires us to make the names of functions and variables descriptive During encoding so that they can tell readers what they are doing, instead of having to spend a lot of time studying it. This reflects the developer's attitude and degree of professionalism to a certain extent.

For example, a message processing function named processmsg and functiona is better? It is obviously the former. As soon as we see its name, we will know what it is.

For another example, there are three variables named loopflag, maxnum, and sumoftwonum, so we can understand their functions at once. The first variable is used as the cycle sign, the second variable is used to store the maximum number, and the third variable is used to store the sum of the two numbers. This is too obvious. You don't have to ask Yuan Fang to figure it out on your own. However, if you name the three variables I, j, and K at the same time, you will not be able to see at a glance what they are for, and it will take a lot of time to read the code, you don't even know how to use it for a few hours. At this moment, your old man asked you how you did things. When you say it, he said you were incompetent. In fact, you are a "dumb eating berberine", and it is strange that others did not write the code.

 

Properly commented vs not allowed

At first glance, we will also notice whether there are comments and whether there are too many comments. This is also intuitive.

If the functions implemented by the Code are complex, it is essential to add comments. When appropriate comments are used to make readers feel that their ideas are suddenly open, they will silently appreciate you. Too few or no comments are required, just as if we were eating. If there is nothing in a bowl of vegetables, you will feel boring and have no appetite. If you put a little chili sauce on it, you will feel a doubling of appetite. Believe it or not, I believe it.

However, there cannot be too many comments, so it cannot hide useful code, and it cannot be overwhelming, so that the code that truly implements the function can be used as a foil. Marx taught us that "Everything must have a degree.

A good annotation format is as follows:

//Note

{

Statement Block

}

 

//Comment B

{

Statement Block B

}

 

//Start with C

Statement D

Statement E

Statement F

//End of comment c

 

With the first impression that the Code gives us, the next step is much easier. In actual development, I have the experience that when I take over the beautiful code, I will be excited and will spend less time to complete the task well. I think no one wants to take over a mess, which not only affects the development progress, but also affects the mood. Maybe you are happy to go to work that day, but your good mood is ruined by the bad code. Are you saying it's a value or not worth it?

To make a good impression on others, we must first make our code a good first impression on others. This is also a good way to cultivate team cohesion.

 

 

 

(My microblogging: http://weibo.com/zhouzxi? Topnav = 1 & WVR = 5, No.: 245924426, welcome !)