Microsoft Senior Software Engineer: It's really hard to read the code

Microsoft Senior Software Engineer: It's really hard to read the code
2011-01-07 13:09
Reading: The original author Eric Lippert, a senior software Design engineer, has been working in Microsoft development since 1996 to help design and implement VBScript, JScript, JScript. NET, Windows Script Host, Visual Studio Tools for Office and C #.

Here's what the article says:

Escalation's engineer, Jeremyk, asked in his blog:

How do you teach people to quickly dig into unfamiliar code (not what they write). The way I learn how to program is very traditional--do it yourself. But I am now very tangled: In the end is to concentrate on reading the source, or write their own. It seems to me that the only effective way is to write it myself.

Eric Lippert: Not joking with Jeremy, writing code is really not hard to read.

First of all, I agree with you that very few people can read code but not write code. It's not like natural writing or speaking, and understanding what others mean doesn't need to understand why they say that. For example, if I say: "There are two ways to write code: one is strict and detailed, the other is vague and sloppy." The former produces a simple tiered wedding cake, while the latter is spaghetti. "The above sentence produces a balanced and humorous effect, but even if the audience and the reader do not understand that I use the" 0 care "and" side-by-side "text skills, I will also understand what I mean. But when it comes to code, it's important to understand both the intent of the code author from the code itself and the expected effect of the code.

So, I went back to that question, and some people needed to cut into the code quickly, but without having to write code, how do we write code that fits those people?

Here's what I try to do when I write code to make it easy for others to read:

Make code compliance tools. Object browsers and IntelliSense although very good, but I tell you, I am the old school. If I can't find what I want, I won't be happy. What makes the code queryable?

Variable names such as "I" are not good. Without a clear error message, you won't be able to find the code easily.

Avoid using names that are prefixes of other names. For example, there is a "perfexecutemanifest" in the code, if there is a "perfexecutemanifestinitialize", this will make me crazy, because every time I query the source in the former, I have to painstakingly filter out all instances of the latter.

Tramp data should use the same name. The so-called "temporary Data" (tramp) refers to the variables passed to method A and to the variables of method B. These two types of variables are actually the same, so it would be better if they had the same name.

Don't use macros to rename things. If there is a method called get_mouseposition, do not do so getter (mouseposition) to declare the method. Because I'm not going to find the actual method name.

Shadowing can cause a lot of problems, please don't use it.

Persist in using a naming pattern. If you intend to use Hungarian nomenclature, then stick to it and use it extensively, otherwise it will backfire. Use Hungarian nomenclature to record data, not storage types, and to record common facts rather than temporary conditions.

Use assertions to record prerequisites (preconditions) and post conditions (postconditions).

Don't abbreviate English words. To be exact, do not abbreviate into outlandish forms. In the scripting engine, there is a variable called "NME", which makes me very mad. It should be called "VariableName".

The C language standard run-time library is not designed to be very good. Don't try to emulate it.

Don't write "smart" code; When the code goes wrong, the programmer who maintains the code has no time to understand your cleverness.

Understand the design intent of programming language features, and use these features to do what they are suited for, not 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. Don't force the interface pointer to be converted into a class pointer, even if you know it's okay.

Divide the source tree by functional unit rather than by organizational structure. For example: In my current team, there are 2 root directories named "Frameworks" and "integration", which are the names of two teams. Unfortunately, the frameworks team has a subdirectory called "Adaptor", and "Adaptor" is a subdirectory of integration, which is very confusing. Similarly, if there are different subtrees with the same subdirectory, some are client components, some are server-side components, some are management components, some are non-administrative components, some are processing components, some are non-processing components, some are retail components, some are internal testing tools. It's going to be a mess.

Of course, I didn't actually answer Jeremy's question-How to debug the code that I didn't write.

It depends on my purpose. If I dig a specific piece of code just because of a bug, I'm going to step through all the code in the debugger, write down the call branch that I "walk through", record which methods are "producers" of a particular data structure, and which methods are "consumers"; I'll also look at the output window to see what's going on. Also open the exception trap because the exception is usually the problem. Set breakpoints; I will record all the opposite of what I suggested above, because these things are likely to mislead me.

If I want to modify it after I understand a piece of code, I usually start with the head of the code, or look for public methods first. I want to know how the class is implemented, how it is extended, how it works, how it is embedded in the entire code. I will try to understand these things before I can understand how these specific parts (code) are implemented. This may take longer, but if you are prepared to change complex code, you should do so.