Editor's note: Eric lippert, author of the original article, is a senior software design engineer who has been working in Microsoft's Development Department since 1996 and has helped design and implement VBScript, JScript, and JScript.. net, Windows Script Host, Visual Studio Tools for office, and C #.
Jeremyk, an escalation engineer, asked in his blog:
How do you teach people to quickly explore unfamiliar Code (not written by themselves )? I learned how to program in a traditional way-coding by myself. But now I am struggling: whether to concentrate on reading the source code or writing it by myself. For me, it seems that the only effective method is to write it by myself.
It's not a joke with Jeremy. It's really hard to write code without reading it.
First of all, I agree that few people can read but not write code. This is not like natural written or spoken language,Understanding what others mean does not need to understand why they say that.. For example, if I say:
"There are two ways to write code: one is strict and detailed, and the other is fuzzy and hasty. The former generates a simple, layered wedding cake, while the latter is pasta ."
The above sentence produces a balanced and humorous effect, but even if the audience and readers do not understand my use of text skills such as "0-handed" and "parallel sentence, it will also understand what I want to say. But when it comes to code, it is extremely important to understand both the intent of the Code author and the expected effect of the Code.
So I went back to that question again. Some people need to cut in the code quickly, but do not need to write code. How can we compile the code suitable for these people?
The following is what I try my best to do when writing code, so that others can read it easily:
- Make code compliance tools. Although object browsers and intelliisense are good, I tell you that I am a regular school. I will be unhappy if I cannot find what I want. What makes the code queryable?
- Variable names such as "I" are not good. Without a clear error message, you cannot easily find the code.
- Do not use names that are prefixed with other names. For example, there is a "perfexecutemanifest" in the Code. If there is another "perfexecutemanifestinitialize", this will make me crazy, because every time I query the former in the source code, I had to struggle to filter out all instances of the latter.
- Tramp data should use the same name. The so-called "temporary data transfer" refers to the variables passed to method A and also to method B. These two types of variables are actually the same, so it is better if they have the same name.
- Do not use macros to rename things. If there is a method named get_mouseposition, do not declare this method using getter (mouseposition. Because I cannot find the actual method name.
- Shadowing may cause many problems. Please do not use it.
- Stick to a naming mode. If you plan to use the Hungarian naming convention, stick to it and use it extensively. Otherwise, it will be counterproductive. Use the Hungary name method to record data, rather than the storage type; record general facts, rather than temporary conditions.
- Preconditions and postconditions are recorded using assertions ).
- Do not abbreviated to an English word. To be exact, do not abbreviated it as an odd form. In the script engine, there is a variable named "NME", which makes me crazy! It should be called "variablename ".
- The C standard Runtime Library is not well designed. Do not follow suit.
- Do not write "smart" code. When a code problem occurs, programmers who maintain the Code do not have time to understand your intelligence.
- Understand the design intent of programming language features and use these features to do what they are suitable for, rather than what they can do. For example, instead of using exceptions as a general flow control mechanism (even if you can), you should use them to report errors. Do not forcibly convert the interface pointer to a class pointer, even if you know it is okay.
- The source code tree is divided by functional units, rather than by organizational structure. For example, in my current team, there are two sub-directories named "frameworks" and "integration", which are the names of the two teams. Unfortunately, the frameworks team has a subdirectory named "adaptor", while "adaptor" is a subdirectory of integration, which is very confusing. Similarly, (IF) there are different sub-trees with the same sub-directories, some are client components, some are server components, some are management components, and some are non-management components; some are processing components, some are non-processing components, some are retail components, and some are internal testing tools. This will be messy.
Of course, I didn't actually answer Jeremy's question --How can I debug code that is not written by me?
It depends on my purpose. If I dig into a specific piece of code just because of a bug, I will track all the code step by step in the debugger and write down the call Branch that I "Walk through, record which methods are "Producers" of specific data structures and which are "consumers". I will also carefully stare at the output window to view useful information and open the exception catcher, because exceptions are usually the problem. Set breakpoints; I will record all the opposite things as I suggested above, because these things may mislead me.
If I want to modify a piece of code after understanding it, I usually start with the code header or look for public methods first. I want to know how a class is implemented, how it is extended, how it works, and how it is embedded in the entire code? I will try my best to understand these things before learning how these specific parts (CODE) are implemented. This takes longer, but if you are about to change complex code, you should do that.
How to read the code? Like some people ......
I don't know how many times I have seen programmers roll up and down and look at unfamiliar code. A few minutes later, their faces were unhappy. They will soon announce that the Code is not worth reading. Why is it a waste of time? We can only solve the problem in other ways. I'm not sure what they are looking for, is it through subtle ways to absorb the meaning of the Code, or is it inspired to concentrate on the code? You must understand the code and use it as your own. Here are some tips I like to use. Although this is not a detailed list, I found some of them are particularly useful.
- 1. Try your best to build and run the code.This is usually a simple step, just as you are looking at the code that can run (this is opposite to the random code ). However, this is not always the case. By building and executing code, you can learn a lot about the Upper-layer code structure. Speaking of work code, are you very familiar with how to build your current project? Although building is usually complex, you can learn a lot by building and generating executable code.
- 2. Do not focus only on details.The first thing you need to do is to find the code structure and style in the code you are reading. First, let's look at the code and try to understand what different code segments need to do. This will familiarize you with the upper-layer structure of the entire code, and you can also understand some ideas about the code you are processing (good architecture and pasta ). At this time, you can find the starting point (no matter what it is, the main function, servlet or controller), and view how the code branches there. Don't spend too much time on it. As you become more familiar with the code, you can come back and check it at any time.
- 3. Make sure you understand all the structures.Unless you happen to be the Chief Expert of the programming language used, you may not know what the language can do. When you are browsing the code, write down all the structures you may not be familiar. If there are many unfamiliar structures, the next step is very obvious. If you don't know what the code is going to do, you can't go far. Even if there are only a few structures you are not familiar with, you should look into them in depth. You are exploring what you didn't know in the programming language you used before, so I am happy to spend a few hours reading the code.
- 4. Since you have a good understanding of most structures, it is time to do some random in-depth research.Like step 2, start to browse the Code. This time, you need to select some random functions or classes and start to view them in detail line by line. This is the beginning of the battle, but it is also the main success you want to achieve. The ideas here will form the thinking mode of the code library you are viewing. Do not spend too much time on this, but before moving on, you should try your best and absorb some code blocks with content. In this step, you can also go back and forth at any time. Every time you learn more about the background and learn more.
- 5. There is no doubt that you are confused in the previous steps, so this is the best time to do some testing.During testing, you may have less trouble and understand the code. I have been wondering that developers try their best to read and understand some code by ignoring a set of well-written and comprehensive test code. Of course, sometimes it is not tested.
- 6. If you say there is no test, it sounds like it is time to write the test.There are many benefits for writing a test. It helps you understand the code base and write code when you read the code. This is the time to do something. Even if you already have a test, you can usually write some tests, and you will always benefit. Testing Code usually requires a different way of thinking about the problem, and the concepts that you didn't know before will become clearer.
- 7. Extract odd code and make it a separate program.I found that reading code is a very interesting exercise, even if it is just for rhythm changes. Even if you do not understand the underlying details of the code, you may be able to know what the code should do in the upper-layer structure. Why not extract some specific functions and separate them as independent programs. Debugging is easier when you execute a short program. On the other hand, some additional steps may be required to understand the code you are viewing.
- 8. The code is not clean? Nose smell?Why not refactor it? I do not recommend that you rewrite the entire code library, but refactoring part of the code really helps you to increase the level of understanding. Take out the functions you understand and change them to independent functions. Before you know it, the old big function looks easy to manage and you can modify it in your mind. Refactoring allows you to change your code into your own, without rewriting the code. If there is a good test, it will help to refactor, but even if you do not have a good test, extract the function you are sure of and perform the test. Even if the test looks totally inadequate, but as a developer, you have to learn to trust your skills. Sometimes you only need to work hard (refactoring ). (If you have to refactor, you can usually restore the code to its original state .)
- 9. If there is nothing to help, you should find a companion reading the code.Maybe you are not the only one who can benefit from this code, so find someone and read the code together. But you don't need to look for experts. They will explain everything to you in the upper layer structure, and you will miss the nuances you can learn when looking at the code in detail. However, if it doesn't work, you can't understand it. Sometimes, the best thing you can do is ask. Ask your colleagues. If you are reading open source code, ask someone on the Internet. But remember, this is the last step, not the first step.
If I need to understand some code quickly and reasonably, and I can only select one of the above steps, I will select "refactoring" (that is, 8th steps ). Although you can understand a lot of things, you will remember the things you understand. In short, you need to remember one thing. If you are new to an important code library, you cannot understand it immediately. This requires days, weeks, and months of painstaking efforts to accept this fact. Even if an expert is with you, the time cannot be significantly shortened. However, when it comes to code libraries, if you can patiently and methodically read (and write) the code, you will eventually be familiar with all aspects of the project, and you will become a great bull. You can also avoid reading code and often ask someone to help you explain something. I know who I will be.
Looking for opportunities to read code-Do not miss out
We like writing new code because we can solve the problem correctly this time. Okay, maybe not this time, but it must be next time. In fact, you often improve your technology, but you never properly handle the problem. This is the value of writing new code. You can experience and hone your skills, but read and play with the Code Compiled by others (if there is no more value ,) it also has the same value. You can not only obtain valuable technical knowledge, but also obtain domain knowledge. domain knowledge is usually more valuable (after all, code is the final form of documentation ).
Even if the code is mysterious and has no conventions, it is still valuable. You know the code I'm talking about. It looks almost obscure, but not intentionally (for some reason, Perl code is usually like this ). No matter when I see such code, I will think like this: think of it as something you can learn only after deciphering it. Yes, this is a major pain point, but accept it. Sometimes you write confusing code for trivial reasons (it's useless to deny it, you know it's true ). Well, if you spend some time reading such code, you are more likely to eventually write the same code. It doesn't mean you will write that code, but you have the ability to write that code. Finally, attitude is usually the most important (Note: Attitude determines everything ). If you consider reading code as a tedious task, it is (tedious work) and you will escape it. But if you regard it as an opportunity, good things will come.
Note: This article Reprinted from http://blog.csdn.net/sdulibh/article/details/38412955
Microsoft Senior Software Engineer: Reading the code is really hard
