Recording as you want (how to read the code)

[Disclaimer: All Rights Reserved. You are welcome to reprint it. Do not use it for commercial purposes. Contact Email: feixiaoxing @ 163.com]

As a programmer, viewing code is a required course. I remember the author of "Cultivation of Linux kernel" said that the best way to learn Linux is to read the code. Hou Jie, author of "getting down to MFC", also said that there is no secret in front of the Code. But is the code really so easy to read? In fact, in my personal experience, some of the Code is not only knowledge, but also a kind of refinement and understanding of the business. In other words, what we see in the Code is not only business processing, but also handling exceptions and emergencies. In some cases, this may influence our understanding of the Code. Being unfamiliar with the language, compiling environment, business, test scenarios, and development ideas of others will become obstacles for us to learn. So, is there any way to improve your ability to view code?

(1) familiar with programming languages

Different projects have different programming languages, which can be clearly viewed on SourceForge and Google Code. There are a lot of open-source projects now. Small code libraries, such as Linux 0.11, have around 20 thousand lines before and after, and there will be no more code to mention, what are Linux 3.0, open office, mplayer, gimp, and Android? Basically, the number of lines of code in each project is more than one million lines. Therefore, if you want to have a basic understanding of open-source projects, you need to have a thorough and detailed understanding of their basic programming languages. It is hard to imagine that a C language or assembly language is not very good. Remember how people can understand Linux.
Kernel code? Of course, these are just the foundation. It is a necessary but not sufficient condition for further improvement.

(2) learn to use the basic functions of open-source projects

Many of my friends have a bad habit of Accessing open source. That is, no matter what project code, he will not care about the November 21, download it, decompress it immediately, and then check the code. As for the functions of this code and how the open-source software is used, he does not care. For example, many friends like Notepad ++, which is also a famous open-source project. If we do not have a clear understanding of the functions of notepad ++, we will put ourselves into the code and there is no breakthrough point. Most open-source projects have undergone years of development, and the entire code volume is far less simple than thousands of lines. Therefore, if you strip away the basic functions of the software and focus only on the Code itself, you will actually learn very little.

(3) Learn to compile code

Compiling code is the basic course for us to learn software. On Widnows, you must learn to use Visual Studio to compile software. on Linux, you must learn tools such as GCC, LD, and makefile, and build your own compiling environment, for different compiling environments, check whether the versions match each other. Even in windows, due to version differences, some software code can only be compiled using a later version of Visual Studio, and some software requires the DirectX library and DDK to participate in the compilation. Therefore, compiling code is not that simple. Taking the UCOS embedded operating system as an example, I believe many people have read its code. But what I want to ask is how many friends actually compile UCOS into executable files?

(4) learn to understand and modify code

After the code is compiled, we often get the execution file. However, these jobs are just some basic work, and we still have a lot of other work to do. For example, what are the entry points of the software? What functions are implemented? What is the basic mechanism? How is the connection between modules? How is the protocol stack or software layered? Before you really understand the code, you need

A) differentiate the code structure, which can be seen from the README file;

B) determine the number of threads in the Code and the functions of each thread;

C) differentiate the data and code trend and clarify the Code Execution Process;

D) be good at looking at the code by taking advantage of the basic functions of the software;

E) add the-G option when compiling the code, so that you can perform one-step debugging and view the data changes in each step;

F) Add new functions to the original open-source module, but do not destroy the original basic architecture and mechanism to verify and deepen your understanding.

(5) Learn to simulate code and reconstruct code

If we look at the code for the purpose of using some lib functions, the above 4 points will be good. However, we often have higher requirements. Through learning, we can find out what are the highlights of the original Open-source software design? Can I simulate its basic skills in the same programming language as soon as possible? Even we can write a similar open-source software by ourselves to achieve more functions, while there is a qualitative improvement in resource utilization and data access speed. When we can simulate the code and refactor the code, we can say that we have a real grasp of the code at that time.

Different people have different purposes for viewing code. However, since we have read the code, we must at least master something and learn something. Otherwise, isn't that a waste of time? No matter what method, there are several principles that must be kept in mind. Otherwise, the effect of the code will be greatly reduced,

1] The code must be fully compiled. codes that cannot be compiled are basically useless;

2;

3] The modification code must be based on a deep understanding of the software, otherwise the bug will be changed more;

4] The code needs to be read and verified repeatedly. Generally, each view has a new harvest;

5] pay attention to mutual views when reading code, which will benefit a lot.