Chapter 4 - Structured Programming

• Annecdote about Dijkstra

  • "Dijkstra concluded that the intellectual challenge of programming was greater than the challenge of theoretical physics"
  • Programming is hard and not many programmers do it well

• Dijkstra wanted to be able to prove a program would work the same way he would prove a mathematical proof

• Problem with the use of the goto statement

  • At it core jumbles code logic. Couples many parts of the code together to the point where it is not possible to abstract logic into smaller functions
  • This is an issue when developers trying to prove code logic, as it becomes hard to follow

• Dijkstra found that there were other uses of goto that did not have this problem

  • these included the selection (conditionals) and iteration (loops) control structures
  • He then opted into using these to maintain the flow of the program giving it an easily readable and testable structure.

• It was later found that all programs can be written using the sequence, selection and iteration structures. These are the building blocks of code.

  • Sequence: statements are processed line by line in order
  • Selection: conditionals, where the program follows some path
  • Iteration: loops, where repetition of steps is required

All programs can be constructed from just three structures

• This ment that all programs could be proven through these three structures

How to prove a program works mathematically? (Formal Proof):

1. Sequence
   • Simple enumertion of statements, tracking the inputs and outputs
2. Selection
   • Follow both paths for every selection and prove through sequence for each path
3. Iteration
   • Solve through math induction
     • Prove for a value of 1 (base case)
     • Prove for N (inductive step)

• Almost all programmers do not use formal proofs to test the validity of their programs.

  • I personally believe writing tests and following TDD is good enough to test functionality of a program and edge cases However, it is interesting that Dijkstra thought formal proofs would be the future of progamming. Maybe if formal proofs were common less bugs would occur?

• Function Decomposition

  • Structured programming allows large functions to be split into smaller functions
  • Each subsequent function being a lower level of abstraction
  • This decomposition allowed for simple proofs to occur

• The Scientific Method Approach

  • Does not look to prove if some theory is correct, rather looks to disprove the theory
  • After many attempts to disprove the theory we say it is true enough
  • Test are falsifiable
  • We can not prove our program correct through a test. We can only prove it does not fail tests.

Conclusion

• Main take aways is that structured programming makes code:
  • Readable for other developers
  • Testable through a predictable control flow
  • Modular through decomposition of functions. Developers can work in parallel on seperate modules
  • Easy to change code as module seperation means high cohesion and low coupling within the program