Reading Unfamiliar Code
Do not begin at line one and hope
Section titled “Do not begin at line one and hope”For a small unfamiliar program, first locate:
- The entry point: top-level Python code or C
main. - External input: arguments, files, or standard input.
- Output and effects: printed text, written files, and exit codes.
- Functions called from the entry point.
- Conditions and loops that decide what happens.
- State that changes along those paths.
Then draw a small map. Names such as parse, validate, and save are hints written by the author, not proof of behavior.
Trace one value
Section titled “Trace one value”Choose one externally controlled value and record each transformation:
| Step | Location | Value/type | Evidence |
|---|---|---|---|
| Entry | argument or file | text | input interface |
| Conversion | parser | integer or structured value | conversion call |
| Decision | condition | compared value | branch expression |
| Effect | output | result | print/write/return |
Mark assumptions: required length, permitted range, terminator, successful allocation, or expected file format. Each assumption suggests a boundary test.
Test before editing
Section titled “Test before editing”Run a normal case, empty case, exact boundaries, just outside each boundary, wrong type, and unexpectedly long input. Record predictions first. If behavior contradicts the map, revise the map before modifying code.
Temporary print statements can confirm state, but keep a clean copy and change one observation point at a time. Instrumentation can alter timing and state; it is evidence with limitations, not divine revelation.
Knowledge check
Question 1 of 2
Knowledge check complete
You answered all 2 questions correctly.
What this gives us as researchers
Section titled “What this gives us as researchers”You now have a repeatable source-level investigation process. The Code Investigation Lab asks you to apply it without being handed the command sequence.