Chapter 2: Basic Programming Elements
19. When analyzing a program for the first time, main is a good starting point.
20. The cascade if-else if-...-else sequence can be seen as a selection structure consisting of mutex selection items.
21. Sometimes, to understand the functions of a program in one aspect, running it may be better than readingSource codeMore appropriate.
22. When analyzing important programs, it is best to first identify important components.
23. Understand local naming conventions and use them to guess the function usage 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 the 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. You need to develop the habit of reading relevant documents when you encounter library elements. This will enhance your ability to read and write code.
28. There are many alternative methods for reading code: 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; I <n; I ++) form of loop execution n times; other forms should be careful.
30. A comparison expression involving 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. When reading a logical multiplication expression, we can think that the expression being analyzed is true with the left expression. when reading the logic and expression, we can think of the table being analyzed similarly.
The expression on the left is false.
34. reorganize the code you control to make it easier to read.
35. Will the conditional operator be used? : Is interpreted as if code.
36. There is no need to sacrifice code for efficiency.
37. EfficientAlgorithmAnd special optimization 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 improve its efficiency.
38. The creative code layout can be used to improve the ease of coding.
39. We can use spaces | temporary variables and brackets to improve the ease of expression.
40. when reading the code you control, you should develop the habit of adding comments.
41. We can make good use of indentation and wise selection of variable names to improve the ease of coding for 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 the diff ignore the blank difference and avoid the change.
The noise introduced by 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. Understand A <n as a * k, K = 2n.
46. Understand A> N as a/k, K = 2n.
47. Analyze only one control structure at a time and regard its content as a black box.
48. view the control expression of each control structure as the assertions of the code it contains.
49. Return, Goto, break, and continue statements, and exceptions, will affect the structured execution process. Because these statements generally terminate or re-start the ongoing loop,
Therefore, we need to reason their behaviors separately.
50. Use the variant and non-Variant Types of complex loops to deduce the loops.
51. Use a change that keeps the meaning unchanged to reschedule the code and simplify code reasoning.
Chapter 3: Advanced c Data Types
52. Understand the functions provided by the construction of specific languages to better understand their code.
53. Identify and classify the reasons for using pointers.
54. In C Programs, 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 | as other
Value alias | represents a string | and directly accesses the system memory.
55. parameters passed by reference can be used to return the function results, or avoid overhead caused by parameter replication.
56. pointer to the array element address. You can access the element at a specific index location.
57. The pointer to the array element and the corresponding array index have the same semantics in the operations on the two.
58. functions that use global or static local variables cannot be 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 the C language combines multiple data elements so that they can be used as a whole to return multiple data elements from the function | construct a chained Data Structure | ing
Data on hardware devices | Network Connections and storage media organization | abstract data types | and object-oriented programming.
62. The shared body is mainly used in the C program to optimize the use of the storage space | implement polymorphism | and access different internal expressions of data.
63. A pointer can be used as an array of n elements after being initialized as a bucket pointing to n elements.
64. internal blocks dynamically allocated 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 the vector, and the underlying implementation is not abstracted.
The arrays of 69. n elements can be completely processed by the sequence for (I = 0; I <n; I ++). All other variants should be vigilant.
70. The expression sizeof (x) will always get the correct number of bytes required to process array X (not a 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 the asymmetric 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; the high boundary represents the first element outside the interval.
75. arrays of structures often represent tables composed of records and fields.
76. A pointer to a structure usually indicates a 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 arrays, which locates their elements 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 efficiently encode control structures to simplify program logic.
82. You can associate code with data by storing a data element and a function pointer (pointing to a function that processes data elements) at each position in the array.
83. Arrays can control program operations by storing data or code used by the abstract machine or virtual machine in the program.
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. To understand the complex data structure, you 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 a 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 a graph are often stored as dynamically allocated arrays or linked lists. In both cases, edges are anchored on the graph node.
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 graph processing.
97. Other types of independent structures may be hidden in complex graph structures.
Chapter 5: Advanced Control Process
98. Recursive defined algorithms and data structures are often implemented using recursive function definitions.
99. When reasoning recursive functions are used, the benchmark outdated test should be started and the code of How to gradually approach the non-recursive reference sample code for each recursive call should be verified.
100. Simple languages often use a series of functions that follow the syntax structure of the language for syntax analysis.
101. Recursive definitions based on underlying concepts should be implemented for mutual inference functions.
102. tail recursive call is equivalent to a loop that returns to the beginning of the function.
103. Remove the throws clause from the method definition, and then run 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 parallel working group model is used to allocate work among multiple processors, or to create a task pool and allocate a large amount of work that needs 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. process-based manager/worker parallel models are generally used to reuse existing programs or 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. 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. Be highly cautious with the data structure operation code and library calls that appear in the signal processor.
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
115. Macro-based tag concatenation allows you to create a new tag.
Chapter 6: dealing with large projects
116. We can analyze the organization of a project by browsing the project source code tree-the hierarchical directory structure containing the project source code. The source code tree often reflects the project architecture and
Software Process structure.
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 large source code sets; they are generally better organized than small specialized projects.
119. It takes some time to familiarize yourself with the directory tree structure of a project when you first get into touch with a large project.
120. The source code of a project is much more than the computer language instruction for executable programs after compilation. The source code tree of a project generally includes specifications | end user and developer documentation |
Test script | multimedia resources | compilation tool | example | localization file | revision history | installation process and license information.
121. The compilation process of large projects is usually declared by dependencies. dependencies are converted into specific compilation actions by tool programs, such as make and its derived programs.
122. In large projectsCompositionParts are often dynamically generated by the configuration steps. Before analyzing the production file, you must first execute the specific configuration of the project.
123. You can use the-n switch of the make program to preview each step of the large-scale compilation process.
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. Use the number in the bug tracking system that appears in the revision log to locate the Problem description 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 debugging output of the program 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. assertion can be used to test algorithm operation steps | parameters received by functions | program control flow | underlying hardware attributes and test case results.
132. You can use assertions that validate the 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 method 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 the code block 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, the 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.
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 code specification as a guide, you should be aware of the definition and limitations of 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 Description of the given user interface is correctly used.
148. After understanding the organization and automation methods of the Project compilation process, we can quickly read and understand the corresponding compilation rules.
149. when checking the system release process, you can often use the requirements of the corresponding release format as a benchmark.
Chapter 8: Documents
150. when reading the code, try to use any documentation that can be obtained.
151. 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 read code.
153. Software Requirement Specification Description is the benchmark for reading and evaluating code.
154. the design specifications of the system can be used as a roadmap of the cognitive code structure. Read the specific code guidelines.
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, and the interface of the code from the Administrator's Manual | file format and Error Elimination
Information.
158. documents can be used 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. The document helps you understand complex algorithms and data structures.
161. Text descriptions of algorithms make opaque (obscure, difficult to understand) code understandable.
162. Documents can often clarify the meaning of identifiers in source code.
163. The document provides the theoretical basis behind non-functional requirements.
164. The 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 problems or bugs.
168. Known defects in the environment 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 the system, the document does not follow the completed implementation, but what the system should look like or will implement 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 in the glossary of the document (if any) | new hacker's dictionary [ray96] | or in
Search for them in the Web search engine.
177. Always view documents with a critical attitude. Pay attention to non-traditional sources, such as comments | standard | publications | test cases | email list | news group | revision log | problem tracking database | cAMP
Pin material | Source Code itself.
178. Documents should always be viewed with a critical attitude. Since documents will never be executed, the testing and formal review of documents rarely reach the same level of code, so documents are often misleading.
Reader, or completely incorrect.
179. we can infer the true intention of the defective code.
180. Be familiar with the general structure and conventions of the documents before reading documents of large systems.
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. One system can (and indeed in major systems) work out multiple different architectural types at the same time. Check the same system in different ways | analyze different parts of the system | or use different levels
Different types of architectures may be discovered through other decomposition.
183. collaborative applications, or semi-autonomous processes that require collaborative access to shared information or resources, generally adopt a centralized repository architecture.
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. When the processing process can be modeled | design and implementation of a series of data transformations, data stream (or pipeline-filter) architectures are often used.
186. Data Stream architecture is often used in an environment for batch automatic data processing, 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 class relationships in the object-oriented architecture.
189. You can input the source code 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. the 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 needs) does not care how the above layer uses it.
193. layer interfaces can be complementary function families that support 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 arrays 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. Different systems can be used. | the unique layered decomposition model is organized across different coordinate axes.
197. Using the 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 to START | stop and coordinate the execution of other system processes and tasks.
199. Many real systems will be favored. When dealing with such systems, do not look for an all-encompassing architecture diagram in vain; different architectural styles should be used as independent but relevant entities.
To locate | identify and understand.
200. The state transition diagram often helps clarify the state machine action.
201. When dealing with 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 organized into a directory or files with a uniform prefix.
The module in 203. 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. functions are generally used to release the resources occupied by objects during their lifetime.
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, to assign each object an identifier
Counter ).
206. In a well-designed class, all fields should be declared as private and provide access to them using public access methods.
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, is to use the pointer of the data element during running.
And function pointer | or object polymorphism implementation.
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 database 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 for various features of the application.
212. Large | distributed systems are often implemented as 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 the original description, understand the correct method of using the framework, and possible misuse.
216. To analyze 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 shapes.
Type.
219. Some frequently-used models do not explicitly indicate their names, because the reuse of architectural design often comes prior to the formation of the model.
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. state machine operations 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, and the specific implementation does not have to follow this structure.
Chapter 10: code reading tools
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 a large source code file.
225. Browse source code files in read-only mode.
226. Use the regular expression ^ function name to find the function definition.
227. Use a regular expression character class to search for variables whose names follow a specific 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 to find the symbols that appear in the same line.
230. Using the tags function of the editor, you can quickly find entity definitions.
231. You can use a specific tag creation tool to add the editor browsing function.
232. Use the Outline View of the editor to obtain the source code structure.
233. Use your editor to check the matching of square brackets and curly brackets 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. 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. Use case-insensitive mode (grep-I) to search for comments or code written in a language where the identifiers are not case sensitive ).
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 appropriate levels of compiler warnings and evaluate the generated results with caution.
249. Use the C Preprocessor to sort out 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 organizations.
254. The beautiful print program and editor syntax coloring can make the program's source code readable.
255. The cdecl program can convert obscure C and C ++ type declarations into pure English (and vice versa ).
256. The actual running of the Program often gives 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 actions, you need to operate it in the debugger.
261. Print codes that are hard to understand to paper.
262. You can draw diagrams to depict code actions.
263. 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. Do not use any computation or automated help.
Chapter 2: 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 commented on in the file switch to illustrate 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. Adopt a breadth-first search strategy to overcome the problems in code reading from multiple parties and find out the methods to overcome them.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
