How do I read the code for a large project?

This article was reproduced from: http://blog.csdn.net/jk110333/article/details/7563718

Technorati Tags: source reading

-------------------------------I'm the beginning of the split line------------------------------------------

++++++++++++++++++++

Chapter One: Introduction

++++++++++++
1. To develop a habit, often spend time reading high-quality code written by others.
2. To selectively read the code, but also to have its own goals. You want to learn a new pattern | coding style | or a way to meet certain requirements.
3. Pay attention to the special non-functional requirements of the Code, which may lead to special implementation styles.
4. When working on existing code, please coordinate with the author and maintenance staff to avoid duplication of effort or to create disgust.
5. Please consider the benefits derived from open source software as a loan and try to find ways to return the open source community as much as possible.
6. In most cases, if you want to know how others will do this, there is no better way than to read the code.
7. When looking for a bug, analyze the code from the presentation of the problem to the source of the problem. Do not follow the irrelevant path (astray).
8. We want to make the most of the debugger | compiler-given warning or symbol code for output | system call Tracker | The log mechanism of the database Structured Query Language | The package Dump tool and Windows message detection program, fixed the location of the bug.
9. For large, well-organized systems, you need to be able to make changes to it by simply knowing the full functionality of it at a minimum.
10. When adding new functionality to the system, the first task is to find code that implements similar features as a template for the functionality to be implemented.
11. From the feature description to the implementation of the code, you can search for the code by string message or by using a keyword.
12. When porting code or modifying interfaces, you can use the compiler to directly locate the scope of the problem, thereby reducing the amount of code reading.
13. When you refactor, you start with a system that works, and you want to ensure that the system works at the end. A set of appropriate test cases can help you meet this constraint.
14. Read the code to find a refactoring opportunity, start with the architecture of the system, and then refine it to get the most benefit.
15. The reusability of the code is a tempting but difficult to understand and separate, and you can try to find more granular packages and even other code.
16. When reviewing software systems, it is important to note that the system is made up of many parts, not just execution statements. Also pay attention to analyzing the following: file and directory structure | Build and Configuration Process | The
user interface and system documentation.
18. Software review can be used as a learning | instruction | To help with the hand and the opportunity to receive assistance.

++++++++++++++++++++

Chapter II: BASIC Programming elements

++++++++++++++++++++
19. When analyzing a program for the first time, main is a good starting point.
20. Cascade If-else If-...-else sequence can be thought of as a selection structure consisting of mutually exclusive selections.
21. Sometimes, to understand the function of a program in one aspect, it may be more appropriate to run it than to read the source code.
22. In analysing important procedures, it is best to identify important components first.
23. Understand the local naming conventions and use them to guess the functional uses of variables and functions.
24. When modifying code based on guesswork, you should design a process that validates the initial assumptions. This process may include checking with the compiler | Introducing Assertions | or executing the appropriate test cases.
25. Understanding a part of the code may help you understand the rest of the code.
26. Hard-to-solve code should start with the easy part.
27. Get into the habit of reading related documents when you encounter library elements; This will enhance your ability to read and write code.
28. Code reading has a number of selectable strategies: bottom-up and top-down analysis | Applying heuristics and checking comments and external documents, you should try all of these methods based on the needs of the problem.
29.for (i=0; i<n; i++) in the form of cyclic execution n times; Be careful in any other form.
30. A comparison expression involving two unequal tests (one of which includes equal conditions) can be considered as interval-member testing.
31. We can often apply an expression to the sample data to understand its meaning.
32. Use the De Morgan rule to simplify complex logical expressions.
33. When reading a logical multiplication expression, the problem can be that the expression being parsed is true for the left expression; Similarly, when reading logic and expressions, you can assume that the expression you are parsing is false on the left.
34. Reorganize the code you control to make it easier to read.
35. Will the conditional runner be used? : The expression is understood as the if code.
36. There is no need to sacrifice the readability of the Code for efficiency.
37. Efficient algorithms and special optimizations can indeed make the code more complex and difficult to understand, but that does not mean that making the code more compact and unreadable can improve its efficiency.
38. Creative code layout can be used to improve the readability of the code.
39. We can use spaces | Temporary variables and parentheses to improve the readability of an expression.
40. When reading the code you control, make the habit of adding notes.
41. We can use good indentation and a wise choice of variable names to improve legibility of poorly written programs.
42. When using the diff program to analyze a program's revision history, if this history spans the overall re-indentation, it is often possible to specify the-w option so that diff ignores whitespace differences and avoids the noise introduced by changing the indentation level.
The loop body of a 43.do loop is executed at least once.
44. When performing arithmetic operations, when b=2n-1, A&b can be understood as a% (b+1).
45. Interpret A<<n as A*k, k=2n.
46. Interpret A>>n as a/k, k=2n.
47. Analyze only one control structure at a time and treat its contents as a black box.
48. Consider the control expression for each control structure as an assertion of the code it contains.
49.return, Goto, break and Continue statements, and exceptions, all affect the structured execution process. Because these statements generally terminate or restart the in-progress loop,
Therefore, they are to be inferred independently of their behavior.
50. Use the variable and invariant of complex loops to infer the loop.
51. Rearrange the code using a constant-meaning transformation to simplify the reasoning of your code.

+++++++++++++++++++

Chapter III: Advanced C data types

+++++++++++++++++++
52. Once you understand the features that a particular language construct serves, you can better understand the code that uses them.
53. Identify and classify the reasons for using pointers.
54. In C programs, pointers are typically used to construct chained data structures | Dynamically allocated Data Structures | Implementing reference calls | Accessing and iterating over the elements | Passing array parameters | referencing functions | As other
The alias of the value | Represents the String | and accesses the system memory directly.
55. Parameters passed by reference can be used to return the result of a function, or to avoid the overhead of parameter duplication.
56. A pointer to the address of an array element to access the element at a particular index location.
57. Pointers to array elements and corresponding array indexes have the same semantics for operations on both.
58. Functions that use global or static local variables are not reentrant in most cases (reentrant).
59. Character pointers are different from character arrays.
60. Identify and classify each of the reasons for applying a structure or a shared body.
The structure in the 61.C language brings together multiple data elements so that they can be used as a whole to return multiple data elements from a function | construct chain data Structure | mapping
How data is organized on hardware devices | network links and Storage Media | Implementing abstract Data Types | And programming in an object-oriented manner.
62. The common body is mainly used in C programs to optimize the use of storage space | To achieve polymorphic | And to access different internal representations of the data.
63. A pointer can be used as an array of n elements after it is initialized to a storage space that points to n elements.
64. Dynamically allocated inner blocks can be released by welders or released at the end of the program, or recovered by the garbage collector; The memory block allocated on the stack is freed when the function that allocates it exits.
The 65.C program uses typedef declarations to promote abstraction and to enhance the readability of code to prevent portability problems and to emulate the class declaration behavior of C + + and Java.
66. A typedef declaration can be understood as a variable definition: The name of the variable is the name of the type; The type of the variable is the type that corresponds to the name.

+++++++++++++++

The fourth chapter: C Data structure

+++++++++++++++
67. Understand explicit data structure operations based on the underlying abstract datatype.
In 68.C languages, it is common to implement vectors using built-in array types and no longer abstract the underlying implementation.
An array of 69.N elements can be fully processed by sequences for (i=0; i<n; i++); All other variants should be vigilant.
70. The expression sizeof (x) always gets the correct number of bytes required to process the array x (not the pointer) with Memset or memcpy.
71. The interval is generally represented by the first element in the interval and the first element after the interval.
72. The number of elements in an asymmetric interval is equal to the difference between the high and low boundaries.
73. The interval is empty when the high-order boundary of the asymmetric interval equals the low-level boundary.
74. The low-level boundary in the asymmetric interval represents the first element of the interval; A high-level boundary represents the first element outside the interval.
75. Arrays of structures often represent tables made up of records and fields.
76. Pointers to structures often represent cursors that access the underlying records and fields.
77. A dynamically allocated matrix is typically stored as a pointer to an array column or pointer to an element pointer; Both of these types can be accessed in two-dimensional arrays.
78. A dynamic allocation matrix stored as an array, using custom access functions to locate their elements.
79. Abstract data types provide a measure of confidence in how the underlying implementation elements are used (or misused).
80. The array is the key in order to organize the lookup table with an integer starting from 0.
81. Arrays are often used to encode control structures efficiently, simplifying the logic of the program.
82. You can associate code with data by storing a data element and a function pointer (to a function that handles data elements) at each location in the array.
83. The array can be operated by storing data or code that is used by the abstract machine in the program or virtual machine (VM).
84. The expression sizeof (x)/sizeof (x[0]) can be understood as the number of elements in the array x.
85. If the structure contains a pointer to the structure itself | The element named next, in general, the structure defines the node of the unidirectional list.
86. The persistence of links to a linked list, such as global | Static or distributed on the heap, often represents the head of the linked list.
87. The structure containing the next and prev pointers to itself may be the nodes of the doubly linked list.
88. Understand pointer manipulation of complex data structures you can draw data elements as squares | The pointer is drawn as an arrow.
89. Recursive data structures are often processed using recursive algorithms.
90. Important data structure operation algorithms are usually parameterized with function parameters or template parameters.
91. The nodes of the graph are often stored sequentially in the array, linked to the linked list, or linked by the edges of the graph.
92. The edges in the diagram are generally not implicitly passed through the pointer, but are explicitly represented as independent structures.
93. The edges of the graphs are often stored as dynamically allocated arrays or linked lists, in which case the edges are anchored to the nodes of the graph.
94. In a non-directed graph, all nodes should be considered equal when expressing data, and similarly, the code for processing tasks should not differentiate edges based on their orientation.
95. In a non-connected diagram, the execution traversal code should be able to turn on orphaned sub-graphs.
96. When working with diagrams that contain loops, the traversal code should avoid looping through the loops in the processing diagram.
97. In a complex diagram structure, other types of independent structures may be hidden.

+++++++++++++++++

Fifth chapter: Advanced control process

+++++++++++++++++
98. Algorithms and data structures using recursive definitions are often implemented using recursive function definitions.
99. When reasoning a recursive function, start with the benchmark backward test and certify how each recursive call approaches the non-recursive benchmark sample code.
100. Simple languages often use a series of functions that follow the grammatical structure of the language for parsing.
101. When reasoning the reciprocal recursive function, it is based on the recursive definition of the underlying concept.
102. The tail recursive call is equivalent to a loop returning to the beginning of the function.
103. Removing the throws clause from the definition of the method and then running the Java compiler to compile the source code of the class makes it easy to find methods that might implicitly generate an exception.
104. Code that runs on a multiprocessor computer is often organized around processes or threads.
105. The Working Group parallel model is used to distribute work across multiple processors, or to create a task pool and then allocate a large amount of work that needs to be handled for standardization.
106. Thread-based manager/worker parallel models typically assign time-consuming or blocking operations to worker subtasks, thus maintaining the responsiveness of the central task.
107. Process-based manager/worker parallel models are generally used to reuse existing programs, or to organize and separate coarse-grained system modules with well-defined interfaces.
108. In pipeline-based parallel processing, each task receives some input, processes them, and passes the resulting output to the next task for different processing.
109. Competitive conditions are difficult to fathom, and the associated code often spreads the competition to multiple functions or modules; It is therefore difficult to isolate problems caused by competitive conditions.
110. Maintain a high level of vigilance for data structure operation code and library calls that appear in the signal processor.
111. When reading the code that contains the macro, be aware that the macro is neither a function nor a statement.
A macro in a 112.do...while (0) block is equivalent to a statement in a control block.
113. A macro can access all local variables visible at its point of use.
114. Macro call can change the value of a parameter
115. Macro-based tag stitching creates a new marker.

+++++++++++++++++

Sixth: Dealing with large-scale projects

+++++++++++++++++
116. We can analyze how a project is organized by browsing the project's source tree-a hierarchical directory structure that contains project source code. The source tree can often reflect the structure of the project in the framework and software process.
117. The application's source tree is often a mirror image of the application's deployment structure.
118. Do not be intimidated by the huge collection of source code; They are generally better organized than small, specialized projects.
119. When you first reach a large project, take some time to familiarize yourself with the project's tree structure.
120. The source code of the project is far more than just compiling a computer language instruction that can obtain executable programs; A project's source tree also generally includes specifications | End user and Developer documentation | Test Scripts | Multimedia Resources | compilation Tools | examples | localization files | revision history | Installation process and licensing information.
121. The compilation process for large projects is generally declarative by relying on dependency relationships. Dependencies are translated into concrete compilation actions by tool programs, such as make and its derived programs.
122. In large projects, production files are often generated dynamically by configuration steps; Before you can parse a file, you need to perform a project-specific configuration.
123. When checking the steps of a large compilation process, you can rehearse using the-n switch of the Make program.
124. The revision control system provides a way to get the latest version of the source code from the repository.
125. You can match the executable file to its source code by using the relevant command to display the revision identification keyword in the executable file.
126. You can find a description of the problem in the database of the bug tracking system by using the bug in the revision log to track the number in the system.
127. You can use the revision control system's version repository to find out how a particular change is implemented.
128. Custom compilation tools are used in many aspects of the software development process, including configuration | compilation process Management | code Generation | Testing and documentation.
129. The debug output of the program can help us understand the key parts of the control process and data elements.
130. The location of the trace statement is generally an important part of the algorithm's operation.
131. You can use assertions to test the operation of the algorithm | The parameters that the function receives | The control flow of the program | The properties of the underlying hardware and the results of the test case.
132. You can use assertions that validate the algorithm to validate your understanding of the operation of the algorithm, or as a starting point for reasoning.
133. Assertions about function parameters and results often record the pre-condition and post-condition of the function.
134. We can test the assertion of the entire function as a specification for each given function.
135. The test case can partially replace the function specification.
136. The source code sequence can be previewed using the input data of the test case.

+++++++++++++++++++

Seventh: Coding Specifications and conventions

+++++++++++++++++++
137. Once you understand how the file is organized for a given codebase, you'll be able to browse its source code more efficiently.
138. When reading the code, first make sure that the tab settings of your editor or graceful print program are consistent with the style specifications followed by your code.
139. You can use the indentation of the code block to quickly grasp the overall structure of the code.
140. Adequate vigilance should be given immediately to code that is inconsistent with the orchestration.
141. When parsing code, be careful about code sequences labeled XXX, Fixme, and TODO: errors may lurk in them.
142. Constants are named with uppercase letters, and the words are separated by underscores.
143. In a program that follows the Java coding specification, the package name always starts with a top-level domain name (for example, org, COM), the class name and interface name start with uppercase letters, and the method and variable names begin with lowercase letters.
144. The prefix type tag of the Hungarian notation before the user interface control name can help us determine its role.
145. Different programming specifications have different propositions for the composition of the portable structure.
146. When reviewing the portability of code, or using a given coding specification as a guideline, be aware of the definition and limitations of the specification for portability requirements.
147. If the GUI functionality is implemented using a corresponding programming structure, code review makes it easy to verify that the specification for a given user interface is being used correctly.
148. After understanding how the project compiles and automates the process, we can quickly read and understand the corresponding compilation rules.
149. When checking the system's release process, it is often possible to benchmark the requirements of the corresponding release format.

++++++++++++

Eighth Chapter: Documentation

++++++++++++
150. When reading the code, you should make the best possible use of any documents available to them.
151. Reading the one-hour code is just the equivalent of reading a minute document.
152. Use the system's specification documentation to understand the operating environment of the code you are reading.
153. The software Requirements specification is a benchmark for reading and evaluating code.
154. The system's design specification can be used as a roadmap for the cognitive code structure and to read the instructions for the specific code.
155. The Test specification documentation provides us with the data that can be used to rehearse the code.
156. When exposed to an unknown system, functional descriptions and user guides can provide important background information to better understand the context in which the code is read.
157. From the user reference manual, we can quickly obtain, the application in the visual and logical background knowledge, from the Administrator's manual can learn the code interface | file format and error messages details.
158. Use the documentation to get a quick overview of the system and learn about the code that provides specific features.
159. Documents often reflect and prompt the underlying structure of the system.
160. Documentation helps to understand complex algorithms and data structures.
161. The text description of the algorithm makes it understandable that opaque (obscure, incomprehensible) code can be made.
162. Documentation can often clarify the meaning of identifiers in the source code.
163. Documentation provides the rationale behind non-functional requirements.
164. The documentation also describes the internal programming interface.
165. Because the document is rarely tested like actual program code and is subject to concern, it can often have errors | incomplete or obsolete.
166. The documentation also provides test cases, as well as examples of practical applications.
167. The documentation often also includes known implementation issues or bugs.
168. The known weaknesses in the environment are generally recorded in the source code.
169. Changes to the document can mark those points of failure.
170. Repeated or conflicting changes to the same source code often indicate a fundamental design flaw, which allows maintenance personnel to be repaired with a series of patches.
171. Similar fixes are applied to different parts of the source code, often indicating an error or omission that can be easily committed, and they may also exist elsewhere.
172. Documentation often provides inappropriate information, misleading our understanding of the source code.
173. Be wary of features that are not archived: classify each instance as reasonable | negligent or harmful, and decide whether to fix the code or document accordingly.
174. Sometimes, the document describes the system, not according to the completed implementation, but the system should look like or future implementation.
175. In the source code document, the meaning of the word gork is generally referred to as "comprehension".
176. If an unknown or special usage word hinders the understanding of the code, try the glossary in the document (if one exists) | New Hacker ' s dictionary[ray96]| or in
Find them in the web search engine.
177. Always take a critical look at the document, paying attention to non-traditional sources such as annotations | standard | publications | Test Cases | mailing Lists | newsgroups | Revision Log | Issue Tracking database | marketing Materials | source code itself.
178. Always look at the document in a critical manner; Because documents are never executed, testing and formal review of documents is rarely the same level of code, so documents are often misleading to readers, or completely wrong.
179. For those defective code, we can infer its true intentions from it.
180. When reading documentation for large systems, first familiarize yourself with the overall structure and conventions of the document.
181. When dealing with bulky documents, you can use tools or output text to high-quality output devices, such as laser printers, to improve reading efficiency.

++++++++++++++

The Nineth Chapter: System Architecture

++++++++++++++
182. A system can (and is true in a major system) simultaneously produce many different types of architectures. Examine the same system in different ways | Different parts of the analysis system | or using different levels of decomposition, it is possible to find different architectural types.
183. Collaborative applications, or semi-autonomous processes that require collaborative access to shared information or resources, typically use a centralized repository architecture.
184. The blackboard system uses a centralized repository, storing unstructured key/value pairs as a communication hub between a large number of different code elements.
185. When the process can be modeled | Designing and Implementing a series of data transformations, the data flow (or pipeline-filter) architecture is often used.
186. In an environment where automatic data processing is done in bulk, the data flow architecture is often used, especially on platforms that provide a large amount of support for the tool.
187. A clear indication of the data flow architecture is that the program uses temporary files or pipelining (pipeline) to communicate between different processes.
188. Use diagrams to model the relationships of classes in the object-oriented architecture.
189. You can input the source code into the modeling tool, and deduce the structure of the system backwards.
190. Systems with a large number of sibling subsystems are often organized in a hierarchical framework.
191. Layered architectures are typically implemented by stacking software components that have standardized interfaces.
192. Each layer in the system can think of the following layer as an abstract entity, and (as long as the layer satisfies its requirements description) does not care how the layer above uses it.
193. The interface of a layer can be either a complementary function family that supports a particular concept, or a series of interchangeable functions that support different underlying implementations of the same abstract interface.
194. A system implemented in C language, often using an array of function pointers, to express the multi-multiplexing operation of the layer interface.
195. Using the object-oriented language implementation of the system, the use of virtual method calls directly to express the operation of the layer interface.
196. The system can be organized across a variety of axes using different | unique hierarchical decomposition models.
197. Using program slicing technology, you can centralize the dependencies between data and control in your program.
198. In a concurrent system, a separate system component acts as a centralized manager, responsible for initiating | Stopping and coordinating the execution of other system processes and tasks.
199. Many real-world systems will be in the family. When dealing with such systems, do not search in vain for all-encompassing architectural diagrams; Different architectural styles should be positioned as separate but related entities | To identify and understand.
200. The state transition diagram often helps to clarify the action of the state machine.
201. When dealing with large amounts of code, it is important to understand the mechanism by which the code is decomposed into separate units.
202. In most cases, the physical boundary of a module is a single file | A collection of multiple files organized into a directory or files that have a uniform prefix.
The module in 203.C consists of a header file that provides the module's public interface and a source file that provides the corresponding implementation.
204. The object's constructor is often used to allocate resources related to the object and initialize the state of the object. Functions are typically used to release resources that the object occupies during life.
205. Object methods often use class fields to store data that controls the operation of all methods (such as lookup tables or dictionaries) or to maintain state information for the operation of a class (for example, a counter that assigns an identifier to each object).
206. In well-designed classes, all fields should be declared private, and access to them is provided using public access methods.
207. When you encounter a friend statement, stop and analyze to see the reason for bypassing the class encapsulation for the design.
208. It is not appropriate to use operators sparingly to enhance the availability of a particular class, but with operator overloading, it is inappropriate to implement the class as a class entity that has all the functionality associated with the built-in arithmetic types.
209. Generic implementations are not implemented during compilation through macro substitution or language-supported features such as C + + templates and Ada generic packages, which are implemented during run time by using pointers to data elements and pointers to functions | or the polymorphism of the objects.
210. Abstract data types are often used to encapsulate commonly used data organization scenarios such as tree | lists or stacks, or to hide the implementation details of a data type from a user.
211. The library is used for a variety of purposes: reusing source code or target code, organizing module collections, organizing and optimizing the compilation process, or enabling on-demand onboarding of various features of the application.
212. Large | Distributed systems are often implemented as a number of collaborative processes.
213. For a text-based data repository, you can decipher its structure by browsing the data stored therein.
214. You can analyze the schema of a relational database by querying the tables in the data dictionary, or by using database-specific SQL commands, such as show table.
215. Once you have identified the reusable architectural elements, you can find their original descriptions, understand the proper way to use the architecture, and the possible misuse.
216. To analyze in detail the applications built on a certain framework, the best course of action is to start with the research framework itself.
217. When reading the code generated by the wizard, do not expect too much, or you will be disappointed.
218. After learning a few basic design patterns, you will find that the way you view the code architecture changes: Your horizons and vocabulary will expand to identify and describe many common forms.
219. Frequently used patterns, but do not explicitly indicate their names, because the reuse of architectural design is often preceded by pattern formation.
220. Try to understand the architecture according to the underlying schema, even though the code does not explicitly refer to the schema.
221. Most interpreters follow a similar processing architecture, built around a state machine, and state machine operations depend on the current state of the Interpreter | program directives and program state.
222. In most cases, the Reference Architecture simply assigns a conceptual structure to the application domain, and the implementation does not have to follow this structure.

+++++++++++++++++

Tenth chapter: Code reading Tools

+++++++++++++++++
223. Vocabulary tools can efficiently find a pattern in a large code file or across multiple files.
224. Use the program editor and regular expressions to find commands and browse through large source code files.
225. Browse the source code files in read-only mode.
226. Use the regular expression ^function name to find out the definition of the function.
227. Using the character class of a regular expression, you can find variables that have names that follow a specific pattern.
228. Use the negative character class of the regular expression to avoid non-positive matches.
229. Use the regular expression symbol-1. *symbol-2, you can find symbols that appear on the same line.
230. Using the editor's tags feature, you can quickly find out the definition of an entity.
231. You can create a tool with a specific tag to increase the browsing function of the editor.
232. Use the outline view of the editor to get a bird's eye image of the source code structure.
233. Use your editor to detect parentheses in the source code | The matching of square brackets and braces.
234. Use grep to find code patterns across multiple files.
235. Use grep to position the declaration of a symbol | definition and application.
236. When you cannot express exactly what you are looking for, use the stem of the key word to find the source code of the program.
237. Use grep to filter the output generated by other tools to isolate the item you are looking for.
238. Transfer the output of grep to other tools to automate complex processing tasks.
239. Reuse the results of code lookups by streaming edits to the output of grep.
240. Filter the false grep output by selecting an output line (GREP-V) that does not match the noise mode.
241. Use Fgrep to find a list of strings in the source code.
242. Use case insensitive pattern matching (grep-i) when looking for comments, or code written in an identifier case-insensitive language.
243. Using the grep–n command-line switch, you can create a checklist of files and line numbers that match a given regular expression.
244. You can use diff to compare differences between different versions of a file or program.
245. When running the diff command, you can use Diff–b to make the file comparison algorithm ignore the trailing spaces, and use –w to ignore the differences in all white space, using –i to make the file comparison insensitive to case.
246. Don't be afraid to create your own code-reading tools.
247. When building your own code reading tools: to take full advantage of the capabilities provided by the modern rapid prototyping language; Start from the simple, gradually improve as needed; Use a variety of heuristics using code vocabulary structures; To allow some output noise or silence (unrelated output or missing output); Use other tools to preprocess the input or post-process the output.
248. To make the compiler yours: Specify the appropriate level of compiler warnings and carefully evaluate the resulting results.
249. Use the C preprocessor to clarify those programs that misuse the preprocessor features.
250. To thoroughly understand how the compiler handles a particular block of code, you need to look at the generated symbol (assembly) code.
251. By analyzing the symbols in the corresponding target file, you can clearly understand the input and output of the source file.
252. Browse through a large collection of code and object types using the source code browser.
253. Resist the temptation to beautify the external code according to your coding specifications; Unnecessary orchestration changes create different code and hinder the organization of the work.
254. Graceful printing program and editor syntax coloring can make the source code of the program easy to read.
255.CDECL programs can convert hard-to-understand C and C + + type declarations into plain English (and vice versa).
256. The actual operation of the program, often can be more profound understanding of the program's action.
257. System Call | Events and packet trackers can improve understanding of program actions.
258. The execution profiler can identify the code that needs to be optimized, validate the coverage of the input data, and analyze the action of the algorithm.
259. By examining the lines of code that have never been executed, you can identify the weaknesses of the test coverage and modify the test data accordingly.
260. To explore every detail of a program's dynamic action, you need to work with it in the debugger.
261. Print the code you find difficult to understand on paper.
262. You can draw an illustration to depict the action of the Code.
263. You can try to introduce the code you are reading to others, which generally improves your understanding of the code.
264. To understand complex algorithms or ingenious data structures, choose a quiet environment, and then concentrate on it, without resorting to any computerized or automated help.

+++++++++++++++++++++

The 11th chapter: a complete example

+++++++++++++++++++++
265. When imitating the function of the software, follow the lines of similar entities (Class | function | module). In a similar existing entity, to simplify text lookups to the source code base, you should choose a rare name.
266. Auto-generated files often have a comment on the file's switch to illustrate this situation.
267. If you attempt to analyze the code accurately, you will typically fall into a large number of classes | files and modules that will soon overwhelm us; Therefore, we must limit the code that needs to be understood to an absolutely necessary scope.
268. Adopt a breadth-first search strategy to solve the problems in code reading from multiple parties, and go to find ways to overcome them.

-----------------------------I'm the end of the split line-------------------------------------------------

How do I read the code for a large project?