Program Development: Algorithm, Flowchart, Debugging, Compilation and Simple C Programs
This domain tests the process around the code: turning a problem into an algorithm, drawing the flowchart, building the executable through the compiler stages, and finding the bugs that remain.
From problem to program
The usual sequence is: understand the problem, write an algorithm, draw a flowchart, code it, compile, run and debug. An algorithm must be finite, definite (each step unambiguous), effective, with zero or more inputs and one or more outputs. Pseudocode uses READ, SET, IF ... THEN ... ELSE, WHILE ... ENDWHILE.
Flowchart symbols
Oval - start or stop. Parallelogram - input or output. Rectangle - process or assignment. Diamond - decision, with two exits labelled Yes and No. Arrows - direction of control flow. Circle - connector to another part of the chart.
Compilation
Four stages: preprocessing, compilation to assembly, assembly to object code, and linking with library objects to produce the executable. With GCC, -E stops after preprocessing, -S after compilation, -c after assembly, and plain gcc links. Errors are compile-time (syntax, undeclared identifier), run-time (division by zero, null dereference) or logical (the program runs but the formula is wrong).
Worked example
Largest of three numbers: read a, b, c; set max = a; if b > max then max = b; if c > max then max = c; print max. A trace table with a=3, b=7, c=5 shows max becoming 7 at the second step and staying 7 at the third.
Debugging
Insert printf statements to print intermediate values, dry-run the code with a trace table, and use a debugger's breakpoints, single-stepping and watch expressions. Compile with warnings enabled (-Wall) and read them; a warning often marks the real bug.
Traps
- Writing
=instead of==in a condition. - A loop whose counter is never updated, giving an infinite loop.
- A decision diamond drawn with only one exit.
- Assuming a program that compiles is therefore correct.