- An inconsistent coding style
- A gratuitously complicated or unreadable structure
- Obvious logical errors or omissions
- Overuse of nonportable constructs
- Lack of maintenance
3 Read code selectively and with a goal in your mind .
Are you trying to learn new patterns, a coding style, a way to satisfy some requirements? Alternatively, you may find yourself browsing code to pick up random gems. In that case, be ready to study in detail interesting parts you don't know: language features (even if you know a language in depth, modern languages evolve with new features),
API s, algorithms, data structures, architectures, and design patterns.
4 Notice and appreciate the code's particular nonfunctional requirements that might give rise to a specific implementation style .
Requirements for portability, time or space efficiency, readability, or even obfuscation can result in code with very peculiar characteristics.
5 Sometimes you may find yourself reading code from an environment completely foreign to you (computer language, operating system, or
API ). Given a basic familiarity with programming and the underlying computer science concepts, you can in many cases use source codeas a way to teach yourself the basics of the new environment. However, start your reading with small programs ; do not immediately dive into the study of a large system. Build the programs you study and run them. This will provide you with both immediate feedback on the way the code is supposed to work and a sense of achievement. The next step involves actively changing the code to test your understanding . Again, begin with small changes and gradually increase their scope. Your active involvement with real code can quickly teach you the basics of the new environment . Once you think you have mastered them, consider investing some effort (and possibly
some cash) to learn the environment in a more structured way. Read related books, documentation, or manual pages, or attend training
6 The key concept when you are using code as exemplar is to be flexible .
Be prepared to use a number of different strategies and approaches to understand how the code works. Start with any documentation you might find (see Chapter 8 ). A formal software design document would be ideal, but even user documentation can be helpful. Actually use the system to get a feeling of its external interfaces. Understand what exactly are you actually looking for: a system call, an algorithm, a code sequence, an architecture? Devise a strategy that will uncover your target. Different search strategies are effective for different purposes. You may need to trace through the instruction execution sequence, run the program and place a breakpoint in a strategic location, or textually search through the code to find some specific code or data elements 。
7 Once you locate the desired code, study it, ignoring irrelevant elements .
This is a skill you will have to learn.If you find it difficult to understand the code in its original context, copy it into a temporary file and remove all irrelevant parts . The formal name of this procedure is slicing but you can get the idea by examining how we have informally applied it in the book's annotated code examples.
8 In other cases code, rather than being an exemplar, may actually need fixing .
If you think you have found a bug in a large system, you need strategies and tactics to let you read the code at increasing levels of detail until you have found the problem. The key concept in this case is to use tools . Use the debugger, the compiler's warnings or symbolic code output, a system call tracer, your database's this case is to use tools Structured Query Language ( SQL ) logging facility, packet dump tools, and Windows message spy programs to locate a bug's location. .Examine the code from the problem manifestation to the problem source. Do not follow unrelated paths.
9