How to read source code -- reprinted

Chapter 1: Introduction to ++ 1. to develop a habit, we often spend time reading high-quality Code Compiled by others. 2. you must read the code selectively and have your own goals. do you want to learn new models, encoding styles, or methods that meet certain requirements. 3. pay attention to and pay attention to special non-functional requirements in the Code. These requirements may lead to special implementation styles. 4. when working on existing code, please make necessary coordination with the author and maintenance personnel to avoid repetitive work or aversion. 5. please regard the benefits gained from open source software as a loan and try your best to find ways to return to the open source community. 6. in most cases, if you want to know how others will complete this function? ", There is no better way except to read the code. 7. when looking for bugs, analyze the code from the problem presentation form to the root cause. do not follow unrelated paths (go astray ). 8. we need to make full use of the debugger | warning given by the compiler or the signed code output | System Call tracker | log mechanism of the database structured query language | package dump tool and Windows message detection program, the location of the specified bug. 9. for large and well-organized systems, you only need to have a minimum understanding of all its functions to make modifications to it. 10. when adding new features to the system, the first task is to find code that implements similar features and use it as a template for the features to be implemented. 11. from feature description to code implementation, you can search for code by string message or keyword. 12. when porting code or modifying interfaces, you can use the compiler to directly locate the scope involved in the problem, thus reducing the workload of code reading. 13. during refactoring, you start from a system that can work normally and want to ensure that the system works normally at the end. A set of proper test cases (Test case) can help you meet this constraint. 14. when reading the code to find the opportunity for refactoring, we should first begin with the system architecture, and then gradually refine it to maximize the benefits. 15. code reusability is very attractive, but it is difficult to understand and separate, you can try to find more granular packages, or even other code. 16. when reviewing the software system, you should note that the system consists of many parts, not just execution statements. analyze the following content: file and directory structure | generation and configuration process | user interface and system documentation. 18. software review can be used as a learning | teaching | helping and receiving opportunities. chapter 2: basic programming elements: +++ ++ 19. when analyzing a program for the first time, main is a good starting point. 20. cascade if-else if -... -The else sequence can be viewed as a selection structure composed of mutex selection items. 21. sometimes, to understand the functions of a program in one aspect, it may be more appropriate to run the program than to read the source code. 22. in When analyzing important programs, it is best to first identify important components. 23. understand local naming conventions and use them to guess the functions of variables and functions. 24. when modifying code based on guesses, you should design a process that verifies the initial assumptions. this process may include checking with a compiler | introducing assertions | or executing appropriate test cases. 25. understanding a part of the Code may help you understand the remaining code. 26. the code to solve the problem should start with the easy part. 27. the habit of reading relevant documents when you encounter library elements will enhance your ability to read and write code. 28. code reading has many optional policies: bottom-up and top-down analysis | apply the test method and check comments and external documents, and try all these methods based on the needs of the problem. 29.for (I = 0; i30. A comparison expression that involves two unequal tests (one of which includes equal conditions) can be considered as a range Member test. 31. we can often apply an expression to sample data to understand its meaning. 32. use the De Morgan rule to simplify complex logical expressions. 33. before reading When using the logic expression, you can consider that the expression being analyzed is true in the left expression. when reading the logic and expression, similarly, the expression being analyzed can be considered as false.34. the code you control is reorganized to make it easier to read. 35. will the conditional operator be used?: Is interpreted as if code. 36. you do not need to sacrifice the ease of coding for efficiency. 37. efficient Algorithms and special optimizations may make the code more complex and more difficult to understand, but this does not mean that making the code more compact and hard to read will increase its efficiency. 38. creative code layout can be used to improve the ease of coding. 39. we can use spaces | temporary variables and parentheses to increase the ease of expression. 40. when reading the code you control, You need to develop the habit of adding comments. 41. we can make good use of indentation and the wise choice of variable names to improve the ease of writing poor programs. 42. when you use the diff program to analyze the revision history of a program, if this history spans the overall contraction, you can often specify the-W option to let diff ignore the blank difference, avoid noise caused by changes to the indentation level. 43. the do loop must be executed at least once. 44. when B = 2n-1 is executed in arithmetic operations, A & B can be interpreted as a % (B + 1 ). 45. interpret a as a * k, K = 2n. 46. consider a> N as a/k, K = 2n. 47. only one control structure is analyzed at a time, and its content is regarded as a black box. 48. think of the control expression of each control structure as the assertions of the code it contains. 49. return, Goto, break, and continue statements and exceptions affect the structured execution process. since these statements usually terminate or re-start the ongoing loop, separate reasoning is required. 50. use the variant and non-Variant Types of complex loops to deduce the loops. 51. re-arrange the code by changing the meaning to simplify the code reasoning. chapter 3: advanced c Data Types. after understanding the functions of a specific language structure, you can better understand the code that uses them. 53. identify and classify the reasons for using pointers. 54. in C program, pointers are generally used to construct chained data structures | dynamically allocated data structures | implement reference calls | access and iterate data elements | transmit array parameters | reference functions | alias as other values | string | and direct access to system memory. 55. parameters passed by reference can be used to return the results of the function or avoid overhead caused by parameter replication. 56. A pointer to the address of an array element to access the element at a specific index location. 57. the pointer to an array element and the corresponding array index have the same semantics in the operation. 58. functions that use global or static local variables are not reentrant in most cases ). 59. character pointers are different from character arrays. 60. identify and classify each reason for the application structure or shared body. 61. the structure in C Language aggregates multiple data elements so that they can be used as a whole, return multiple data elements from a function | construct a chained Data Structure | map data to a hardware device | organize network connections and storage media | implement abstract data types | and use object-oriented programming. 62. the shared body is mainly used in C Programs to optimize the use of storage space | implement polymorphism | and access different internal expressions of data. 63. A pointer can be used as an array of n elements after it is initialized to a bucket pointing to n elements. 64. dynamic score The internal block can be released by welders, released at the end of the program, or recycled by the garbage collector. The memory block allocated on the stack is released when the function assigned to it exits. 65. c programs use typedef declarations to promote abstraction and enhance the Code's accessibility, so as to prevent portability issues and simulate class declaration behaviors in C ++ and Java. 66. the typedef declaration can be understood as a variable definition: The variable name is the type name, and the variable type is the type corresponding to the name. chapter 4: c Data Structure ++ 67. understand explicit data structure operations based on the underlying abstract data types. 68. in C language, the built-in array type is generally used to implement vector, and the underlying implementation is not abstracted. 69. the array of n elements can be sequential for (I = 0; i70. expression sizeof (x) will always get the correct number of bytes required to process array X (not a pointer) with memset or memcpy. 71. generally, an interval is represented by the first element in the interval and the first element after the interval. 72. no The number of elements in the interval is equal to the difference between the high boundary and the low boundary. 73. when the high boundary of an asymmetric interval is equal to the low boundary, the interval is empty. 74. the low boundary in an asymmetric interval represents the first element of the interval, and the high boundary represents the first element outside the interval. 75. arrays of structures often represent tables composed of records and fields. 76. the pointer to the structure usually indicates the cursor that accesses the underlying record and field. 77. dynamically allocated matrices are generally stored as pointers to array columns or element pointers. Both types can be accessed based on two-dimensional arrays. 78. A Dynamic Allocation matrix stored in an array and its elements are located using custom access functions. 79. ABSTRACT Data Types provide a measure of confidence for the use (or misuse) of underlying implementation elements. 80. the array uses an ordered integer starting from 0 as the key to organize the query table. 81. arrays are often used to encode control structures efficiently to simplify program logic. 82. by storing a data element and a function pointer (pointing to a function that processes data elements) at each location in the array, You can associate code with data. 83. the array can be stored by the abstract machine in the Program (Data or code used by BSTRACT machine or virtual machine to control program operations. 84. the expression sizeof (X)/sizeof (X [0]) can be interpreted as the number of elements in array X. 85. if the structure contains an element pointing to the structure itself | named next, the structure generally defines the node of the one-way linked list. 86. the persistence (such as Global | static or heap allocation) pointing to the linked list node is often the head of the linked list. 87. the structure containing the next and Prev pointers pointing to itself may be the node of the two-way linked list. 88. the pointer operation that understands complex data structures can draw data elements as boxes | the pointer is an arrow. 89. recursive data structures are often processed using recursive algorithms. 90. important data structure Operation algorithms are generally parameterized using function parameters or template parameters. 91. graph nodes are often stored in arrays sequentially, linked to the linked list, or linked through the edges of the graph. 92. the edges in the graph are expressed explicitly as independent structures instead of implicitly using pointers. 93. the edges of an image are often stored for dynamic distribution. In both cases, the edges are anchored on the node of the graph. 94. in an undirected graph, all nodes should be treated as equivalent when expressing data. Similarly, the Code for processing tasks should not distinguish edges based on their directions. 95. in a non-connected graph, the traversal code should be able to connect to an isolated subgraph. 96. when processing a graph containing a loop, traversing the code should avoid loops in the loop of the Processing Graph. 97. other types of independent structures may be hidden in complex graph structures. chapter 5: advanced Control Process ++ 98. recursive Function definitions are often used for Recursive defined algorithms and data structures. 99. when reasoning a recursive function, it starts from the benchmark outdated test and verifies how each recursive call approaches the non-recursive benchmark sample code. 100. A simple language often uses a series of functions that follow the syntax structure of the language for syntax analysis. 101. recursive definitions based on underlying concepts are required for mutual recursive inference functions. 102. tail recursive call is equivalent to a loop that returns to the beginning of the function. 103. convert thro The Ws clause is removed from the method definition, and then runs the Java compiler to compile the source code of the class, so that you can easily find the methods that may generate exceptions implicitly. 104. code running on a multi-processor computer is often organized around processes or threads. 105. the Working Group parallel model is used to allocate work among multiple processors, or create a task pool and allocate a large amount of work to be standardized. 106. the thread-based manager/worker parallel model generally assigns time-consuming or congested operations to workers subtasks to maintain the responsiveness of central tasks. 107. the process-based manager/worker parallel model is 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 generated output to the next task for different processing. 109. the competition conditions are difficult to predict. The related code often spreads the competition conditions to multiple functions or modules. Therefore, it is difficult to isolate the problems caused by the competition conditions. 110. for Signal Processors 111. When reading code containing macros, note that macros are neither functions nor statements. 112.do... Macros in the while (0) block are equivalent to statements in the control block. 113. A macro can access all local variables visible at its usage point. 114. macro call can change the parameter value by 115. macro-based tag concatenation allows you to create a new tag. chapter 6: to cope with large projects, such as ++ 116. we can analyze the organization of a project by browsing the source code tree of the project, which contains the hierarchical directory structure of the project source code. the source code tree often reflects the structure of a project in terms of architecture and software processes. 117. the source code tree of an application is often an image of the deployment structure of the application. 118. do not be intimidated by a large set of source code; they are generally better organized than small specialized projects. 119. it takes you some time to get familiar with the directory tree structure of a project when you first access a large project. 120. the source code of the Project is far more than the computer language commands that can be executed after compilation; the source code tree of a project generally includes specifications | end users and developers documentation | test scripts | multimedia resources | compilation tools | examples | localization files | revision history | installation process and license information. 121. the compilation process of large projects is usually declared by dependency. dependencies are converted into specific compilation actions by tool programs, such as make and its derived programs. 122. in large projects, the production file is often generated dynamically by the configuration steps. Before analyzing the production file, you must first execute the specific configuration of the project. 123. when checking the steps of a large compilation process, you can use the-n switch of the make program for the rehearsal. 124. the revision control system allows you to obtain the latest source code from the repository. 125. you can use related commands to display the revision identifier keyword in the executable file to match the executable file with its source code. 126. you can use the number in the Bug Tracking System in the revision log to find the description of the problem in the database of the Bug Tracking System. 127. you can use the version repository of the Revision Control System to find out how specific changes are 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 program debugging output helps us understand the key parts of the program control process and data elements. 130. the location of the tracking statement is generally an important part of algorithm operation. 131. you can use assertions to test the algorithm operation steps | parameters received by the function | program control flow | underlying hardware attributes and test case results. 132. you can use an assertion that tests an algorithm to confirm your understanding of the algorithm's operation, or use it as the starting point of reasoning. 133. assertions of function parameters and results often record the pre-and post-conditions of the function. 134. we can use the assertions for testing the entire function as a specification for each given function. 135. test Cases can partially replace function specifications. 136. you can use the input data of the test case to preview the source code sequence. chapter 7: coding specifications and conventions ++ 137. after learning about the file organization mode followed by a given code library, you can more efficiently browse its source code. 138. when reading the code, make sure that the tab settings of your editor or beautiful print program are consistent with the style specifications that the Code complies. 139. you can use the indentation of code blocks to quickly grasp the overall structure of the Code. 140. be alert immediately for codes with inconsistent orchestration. 141. when analyzing code, pay special attention to the code sequence marked as XXX, fixme, and todo: errors may be lurking in it. 142. constants are named in uppercase letters and words are separated by underscores. 143. in a Java code-compliant program, package name always starts from a top-level domain name (for example, org, com). The class name and interface name start with an upper-case letter, the method and variable names start with lowercase letters. 144. the Hungary notation prefix type mark before the user interface control name can help us determine its role. 145. different programming specifications have different ideas on the structure of portable structures. 146. when reviewing code portability, or using a given coding specification as a guide, you should be aware of the definition and limitations of the portability requirements of the Specification. 147. if the GUI functions are implemented using the corresponding programming structure, the code review can easily verify whether the specification of the given user interface is correctly used. 148. after learning about the organization and automation of the Project compilation process, we can quickly read and understand the corresponding compilation rules. 149. when you check the system release process, you can often use the corresponding release format requirements as a benchmark. chapter 8: Document ++ 150. when reading the code, try to take advantage of any documentation that can be obtained. 151. the information obtained by reading the code for one hour is only equivalent to reading the documentation for one minute. 152. use the system specification documentation to understand the running environment of the code you have read. 153. the software requirement specification is the benchmark for reading and evaluating the code. 154. the design specifications of the system can be used as a roadmap for cognitive code structure. Read the specific code instructions. 155. the test specification documentation provides us with data that can be used to preview code. 156. when exposed to an unknown system, the functional description and user guide can provide important background information to better understand the context of the read code. 157. from the user's reference manual, we can quickly obtain the background knowledge of the application in terms of appearance and logic, the Administrator's manual shows the code interface | detailed information about the file format and error message. 158. this document allows you to quickly obtain the system overview and understand the code that provides specific features. 159. documents often reflect and prompt the underlying structure of the system. 160. this document helps you understand complex algorithms and data structures. 161. the text description of the algorithm can make the opaque (obscure, difficult to understand) code understandable. 162. the document can often clarify the meaning of the identifier in the source code. 163. this document provides the theoretical basis behind non-functional requirements. 164. this document also describes the internal programming interfaces. 165. because the document is rarely tested as the actual program code and is concerned, it may often have errors | incomplete or out-of-date. 166. the document also provides test cases and examples of practical applications. 167. documents often include known implementation issues or known defects in the bug.168. environment, which are generally recorded in the source code. 169. the changes in the document can mark the fault points. 170. repeated or conflicting changes to the same source code often indicate fundamental design defects, so that maintenance personnel need to fix them with a series of patches. 171. similar fixes apply to different parts of the source code, often indicating a vulnerable error or negligence, which may also exist elsewhere. 172. documents often provide inappropriate information, misleading our understanding of the source code. 173. be cautious with Unarchived features: classify each instance as reasonable | neglected or harmful, and decide whether to fix the code or document accordingly. 174. sometimes, when describing a system, the document does not follow the completed implementation, but what the system should look like or how it will be implemented in the future. 175. in the source code document, the word gork generally refers to "Understanding ". 176. if an unknown or special usage word hinders your understanding of the code, you can try it in the glossary of the document (if any) | new hacker's dictionary [ray96] | or search for them in the Web search engine. 177. always look at documents with a critical attitude, pay attention to non-traditional sources, for example, comments | standard | publications | test cases | mailing list | news group | revision log | problem tracking database | marketing materials | Source Code itself. 178. the document should always be viewed with a critical attitude. Since the document will never be executed, the testing and formal review of the document will rarely reach the same level of code, so the document will often mislead readers, or completely incorrect. 179. we can infer the true intention of the defective code. 180. when reading documents of large systems, you must first familiarize yourself with the overall structure and conventions of the documents. 181. when dealing with large documents, you can use tools or output text to high-quality output devices, such as laser printers, to improve reading efficiency. chapter 9: System Architecture + ++ 182. A system can (and indeed in a major system) come up with a variety of different architecture types at the same time. check the same system in different ways | analyze different parts of the system | or use different levels of decomposition to discover different architectural types. 183. A centralized repository architecture is generally used for collaborative applications or semi-autonomous processes that require collaborative access to shared information or resources. 184. the blackboard system uses a centralized repository to store unstructured key/value pairs as communication hubs between a large number of different code elements. 185. data Stream (or pipe-filter) architectures are often used when the processing process can be modeled | design and implementation of a series of data transformations. 186. data Stream architecture is often used in batch automatic data processing environments, especially on platforms that provide a large number of support for data tools. 187. an obvious indication of the data flow architecture is that a temporary file or pipeline (pipeline) is used in a program to communicate between different processes. 188. use icons to model the relationship between classes in the object-oriented architecture. 189. source code can be input to the modeling tool to reverse export the system architecture. 190. systems with a large number of subsystems at the same level are often organized according to the layered architecture. 191. a layered architecture is generally implemented by stacking software components with standardized interfaces. 192. in the system, each layer can regard the following layer as an abstract entity, and (as long as this layer meets its requirements) does not care how the above layer uses it. 193. A layer interface can be a complementary function family that supports specific concepts, or a series of interchangeable functions that support different underlying implementations of the same abstract interface. 194. systems implemented in C language often use array of function pointers to express multiplexing of layer interfaces. 195. A system implemented in an object-oriented language uses virtual method calls to directly express multi-mouth multiplexing operations on layer interfaces. 196. the system can use different | unique layered decomposition models to organize across different coordinate axes. 197. using Program Slicing Technology, you can combine the data and control dependencies in the program. 198. in a concurrent system, a single system component acts as a centralized manager and is responsible for starting, stopping, and coordinating the execution of other system processes and tasks. 199. many real systems will be favored by many people. when dealing with such systems, do not look for an all-encompassing architecture diagram in vain; identify different architectural styles as independent but relevant entities | identify and understand. 200. the state transition diagram often helps clarify the state machine action. 201. when processing a large amount of code, it is extremely important to understand the mechanism of breaking the code into individual units. 202. in most cases, the physical boundary of a module is a single file | a collection of multiple files in a directory or files with a uniform prefix. 203. the module in C is composed of the header file that provides the public interface of the module and the source file that provides the corresponding implementation. 204. object constructors are often used to allocate object-related resources and initialize the object state. A function is generally used to release resources that an object occupies during its lifecycle. 205. object methods often use class fields to store data that controls the operation of all methods (such as searching tables or dictionaries) or maintain the status information of class operations (for example, A counter assigned to each object with an identifier ). 206. in a well-designed class, all fields should be declared as private, and public access methods should be used to provide access to them. 207. when encountering a friend statement, stop and analyze it to see why the bypass class is encapsulated in the design. 208. you can use operators to enhance the availability of specific classes in a controlled manner. However, it is inappropriate to use Operator Overloading to implement classes as class entities with all built-in functions related to arithmetic types. 209. generics are not implemented through macro replacement or functions supported by languages during compilation (such as C ++ templates and Ada generic packages, it is implemented by using the pointer of the data element and the pointer of the function | or the object polymorphism during running. 210. abstract data types are often used to encapsulate Common Data Organization solutions (such as tree | list or stack), or to hide implementation details of data types for users. 211. the library is used for a variety of purposes: Reuse source code or target code, organize a module set, organize and optimize the compilation process, or load on demand to implement various features of the application. 212. large | distributed systems often implement many collaborative processes. 213. for a text-based data repository, you can browse the data stored in it and decrypt its structure. 214. you can analyze the relational database mode by querying tables in the data dictionary or using database-specific SQL commands, such as show table. 215. after identifying the Reusable Architecture elements, you can find their original descriptions to understand how to use the framework correctly and the possible misuse. 216. to analyze the applications built on a framework in detail, the best course of action is to start from the research framework itself. 217. when reading the code generated by the wizard, do not expect too much; otherwise, you will be disappointed. 218. after learning several basic design patterns, you will find that the way you view the code architecture changes: your field of view and vocabulary will be extended to the ability to identify and describe many common forms. 219. some frequently used patterns do not explicitly indicate their names, because the reuse of architectural designs often comes prior to the formation of patterns. 220. try to understand the architecture according to the underlying mode, even if the mode is not explicitly mentioned in the code. 221. most interpreters follow a similar processing architecture and are built around a state machine. The operations of a state machine depend on the current state of the interpreter | program commands and Program states. 222. in most cases, the reference architecture only specifies a conceptual structure for the application domain. The specific implementation does not have to follow this structure. chapter 10: code Reading tool ++ 223. vocabulary tools can efficiently find a mode in a large code file or across multiple files. 224. use the program editor and regular expression to search for commands and browse large source code files. 225. view Source code files in read-only mode. 226. use the regular expression ^ function name to find the function definition. 227. you can use the character classes of regular expressions to find variables whose names follow the specified pattern. 228. use the negative character class of the regular expression to avoid non-positive matching. 229. use the regular expression symbol-1. * symbol-2. You can find the symbols that appear in the same line. 230. the tags function of the editor allows you to quickly find entity definitions. 231. you can use a specific tag creation tool to add the editor browsing function. 232. you can use the Outline View of the editor to obtain the source code structure. 233. use your editor to check the matching of parentheses in the source code. 234. use grep to search for code mode across multiple files. 235. use the grep positioning symbol declaration | definition and application. 236. when you cannot accurately describe the content to be searched, use the key word stem to find the source code of the program. 237. use grep to filter the output generated by other tools and separate the items you want to find. 238. deliver grep output to other tools to automate complex processing tasks. 239. you can edit the grep output stream to reuse the code search results. 240. filter the false grep output by selecting the output line (grep-V) that does not match the noise mode. 241. use fgrep to find the string list in the source code. 242. when you search for comments or code written in a language whose identifiers are case-insensitive, use the case-insensitive mode (grep-I ). 243. use the grep-N command line switch to create a checklist for files and row numbers that match the given regular expression. 244. you can use diff to compare the differences between different versions of files or programs. 245. when running the diff command, you can use diff-B to make the file comparison algorithm ignore trailing spaces and use-W to ignore the differences in all blank areas, use-I to make the file more case-insensitive. 246. do not be afraid of creating your own code reading tools. 247. when building your own code reading tools: Make full use of the capabilities provided by the modern rapid prototype language; gradually improve from the very beginning, as needed; use various testing methods using the code vocabulary structure; allow some output noise or silence (irrelevant output or missing output); use other tools to pre-process the input or perform post-processing on the output. 248. to make the compiler yours: specify the appropriate level of compiler warnings and evaluate the generated results with caution. 249. use the C Preprocessor to clarify programs that abuse the features of the Preprocessor. 250. to thoroughly understand how the compiler processes specific code blocks, you need to view the generated symbolic (assembly) code. 251. by analyzing the symbols in the target file, you can clearly understand the input and output of the source file. 252. use the source code browser to browse large code sets and object types. 253. resist the temptation to beautify external code according to your code specifications; unnecessary orchestration changes will create different codes and impede the work of the Organization. 254. the beautiful print program and editor syntax coloring can make the program's source code readable. 255. the cdecl program can convert incomprehensible C and C ++ types to pure English (and vice versa ). 256. the actual running of the Program often gives you a deeper understanding of the program action. 257. system Call | events and data packet tracking programs can improve understanding of program actions. 258. execute the parser to find the code that needs to be optimized, verify the coverage of input data, and analyze the algorithm action. 259. by checking the code lines that have never been executed, you can identify the weaknesses covered by the test and correct the test data accordingly. 260. to explore every detail of a program's dynamic action, you need to operate it in the debugger. 261. print codes that are hard to understand on paper. 262. you can draw diagrams to depict the actions of the Code. 263. you can try to introduce the code you are reading to others. This will improve your understanding of the Code. 264. to understand complex algorithms or clever data structures, You need to select a quiet environment, and then concentrate on it, instead of using any computation or automated help. chapter 4: A complete example: ++ 265. when imitating the functions of the software, it is necessary to follow the line of similar entities (class | function | module ). in similar existing entities, to simplify text search for the source code library, a rare name should be selected. 266. automatically generated files are often annotated in the file switch to describe this situation. 267. if you try to accurately analyze the code, it will usually fall into a large number of classes | files and modules, which will soon overwhelm us; therefore, we must limit the code we need to understand to an absolutely necessary range. 268. this solution uses a breadth-first search strategy to solve the problems in code reading by multiple parties and find out the methods to overcome them.