Briefly describe how to write simple engineering code

After mixing in the jar for so long, I read the code of many students and felt that everyone's code was a bit angry with the books in the school. I didn't have enough details to consider. Sometimes, it feels as uncomfortable as eating a fly.

Based on my personal experience, I would like to briefly describe some basic coding methods for Engineering Code, simple code, and less error-prone code.

1. Engineering Code: First of all, we should consider the gang committing crimes. The era of lone man and big theft has passed. Therefore, we must emphasize that "people" can understand this. Many examples are provided in textbooks, the principle is that the computer can run correctly. The code written can only be viewed by the computer. I think it will take a long time for the author to read it again. This is not a good code.

The engineering project team is often developed by everyone. Your Code may not be used by you, and the next maintainer may not be you. It is convenient to interact with others and convenient to others, one day, when you face a bunch of code that you don't understand, think about it. Start with me and help others.

2. Simply writing a program does not mean that it is too tired to write a single character.

In the Unix era, without a display, the editor is also a line editor. Therefore, every time you knock a line of text, it is money. In addition, the memory is small, and the space used by the compiler is limited. Therefore, old Unix programmers cherish the variable name, function name, and tag, and seldom use more than two characters. This is a historical factor, poor, and childish.

However, most people use G-based memory, LCD display, and IDE, which is so powerful. Please name it for a long time. It's a little ideographic. Don't write down a program, the word "you guess" is everywhere, and people looking at the program are crazy.

3. Annotations: Many textbooks refer to the normative programming as annotations. It seems that this is the only method for easy reading of programs. The teachers in the university have never seen large-scale engineering development, it is understandable to say that I have not worked on hundreds of thousands of lines of code at a time.

However, the pressure on engineering programmers and projects is usually heavy. during development, all the attention is focused on how to implement the requirements. Few people may be idle, patient, elaborate on their own code, or even, A lot of code is written at the last moment before the job is handed in. Therefore, detailed comments are required, which is not operable in engineering development.

At least I can't do it myself. That's why I especially emphasize the ideographic naming and program writing. Even if the programmer does not have a comment, the programmer can understand it literally. Let's just put it down. It's a blessing to look at other people's engineering code without comments.

Well, sometimes it's bad luck. Many programmers write comments during development, post-bug occurs, and when crazy Debugging starts, how can there be time to modify comments? Oh, I can change the program to a different one. It's all so sweet, finally, it is very likely that the comments and code are reversed. As you can see through the comments, it is a matter of course that it will fall into the trap.

Still, don't look forward to comments. Don't trust comments. Pay attention to your own programs and Ideographic features. If you write or write comments on your own, in my team ,. the public functions and methods in the H file must be fully written. The meaning of each entry parameter and the meaning of the return code, the more, the better. Others can call your program correctly, bug will not bother you, This is for yourself. I don't care about other aspects.

4. Let's talk about simplicity. Simply write a program. It doesn't mean that you are a little bit of money. It means that the reader is simple and doesn't turn around in his mind. This is easy to understand. If we make a product, the user has the right say. Your software product may have specific users, but your code itself is also a product, your team partner is your user. You may have heard of empathy. When we write a program, we don't have to think about whether the customer will give birth to a mother, will anyone who will read our code swear?

There are specifications in the team, according to the specifications, do not discuss reasonable and unreasonable, first take care of it, everyone develops reading habits, it is not difficult to read the code.

Write code. Don't be cool. Young people are more or less fond of expressing their own desires. They can understand the common feelings, but control them. For the optimization of an algorithm, I have racked my brains and finally saved the three variables into one variable, which makes the four-fold loop a heavy one. It seems that the level is high. However, the algorithm complexity is high, the audience will be dizzy.

If you don't want to get scolded, write it honestly. Variables in the function are generally created on the floating stack as long as they are not dynamically applied. As the function exits, it is automatically removed and recycled for the next function. The object is similar internally. Therefore, you may want to use a few more variables to write them in an honest and honest manner. It is easy to see. In fact, your mind is clear and easy to make mistakes.

In martial arts novels, what do you mean when I say that the more masters, the less I like to use odd-door weapons, the simpler I am, the more I am? Make things complex, make things mysterious, not competent, and use the simplest moves to solve the most complicated problems. The internal force is enough. Naturally, you can. Cultivate internal strength is to reduce the reliance on recruitment, simple, direct, and go straight to the key. We get the greatest benefit at the lowest cost, don't you?

5. Rules many people think that programming norms are very important when talking about engineering development. As a result, we began to look for the development specifications of large companies. Therefore, the Huawei software development specifications on the Internet were sent to everyone. Whoever dares to say that there is no word, no matter whether it is buried.

Rules are set by people. Every group of people and every development team has their own development direction and common tools. Therefore, programming standards are actually very small-sized, all of them are most effective for current projects, and it is hard to imagine that one is doing it. net Development Team, with Huawei's gcc program specification for the VxWorks project, can do a good job.

What are the best rules? In my understanding, the best practice is the best. After the system design is complete, before the development, the project team will have a short meeting to discuss the specifications, determine the number of large items, and then continue to supplement the project. In many cases, project managers also need to respect the habits of programmers. A programmer's IDE habit of using VC cannot force everyone to use vi to write gcc. There is a question about personalized rules.

Don't get used to it. When you go out and get into the society, you will find that many things are flexible and not static. Many people are crying, and the world is too dark. In fact, they cannot be flexible. In the project team, there are cool people who generally follow the cool people. Their Bad Habits can be changed to team rules. This is also reasonable. If there is no cool people, they will be unified at the interface, there is nothing wrong with the program in it. There are too many methods. As long as the code can be activated, you can basically understand it. In fact, it is OK.

For example, if you haven't done anything before, you should first talk about a lot of rules. It takes half a day for programmers to learn rules and get used to Chengdu. These are all project costs. Jiangshan is easy to change, so it is difficult to change its nature. It is difficult to do project management. How can this problem be solved for everyone? respect everyone's habits and make them rules. Isn't it better?

6. Wheel: I have met many people in my life. There are also many people who like to shoot bricks in the jar. When I speak, I say that the world needs tools and the people who build their own wheels are dummies.

This is true. It is hard to say, right? However, the author suggests that Beginners should not use the wheel of others.

After graduation, you have taken up your job for decades. No one knows whether to write code on a certain platform or language or framework.

Once you get used to the convenience of a framework when you are young, it is difficult to think deeply. As you get older, when you move to the architect position, you will not be able to think much about the underlying features of the architecture. We said that it is always necessary to pay back and enjoy it now. However, the debt of our life must be changed. It will be difficult to study again at the age of 30 or 40.

Many people say nothing about the framework. It is very fast to build a project using the framework. However, if you think about it, which level is high for the people who build the framework and those who use the framework? Which one has a high income? In fact, in many cases, an enterprise architect develops a framework that is shared by the enterprise for a project or product.

Learn to write a queue by yourself, learn to write a stack by yourself, and then import it to the actual project for testing, and make some customized optimization, your level will be rapidly improved.

Come here first. I don't think I have a thorough explanation. If you have any questions, I will try again.