Don't mix two problems and think they are one

Robin2:
Very many Threads that I look at assume (for example) that if there is a line of code that detects a button press it must be immediately followed by the lines of code that cause something to happen.

Separating

  • the code {A} that collects information (for example button presses or instructions over a serial link)
  • from the code {B} that interprets the information
  • and from the code {C} that implements actions

makes program development much easier.

For example, by seeing the job as 3 separate parts each can be thought about without the confusion of the other parts. And each part can be tested on its own.

...R

And don't build A, B , and C all at once. It will become difficult to tell what works and what does not.

  1. Build A and test to make sure it has properly collected the information.
  2. Build B and verify it correctly interprets the information.
  3. Finally build C. Since you know A and B work, any problem with C is related only to C or you have a fundamental problem in A or B.

The use of subroutines will help isolate and build each aspect of the project.

I suggest (and do the same) to make three versions of the program A, B and C. In the case where you find a problem with the fundamental upon reaching point C. You can more quickly fall back, modify and retest A or B (wherever the problem may lie).