A road named NoNameUno

Any large program needs debugging. There are various forms of debugging:Traces, stepping thru the code under a debugger, visible and audible responses to actions, analyzing output against input, and a whole lot of other mechanisms that is most appropriate for the program.

For event driven piece of code, it is almost essential to have debugging code to trace the events and corresponding actions or responses. Protocol implementations, window based applications are some of the examples of event driven programs. And they always need some sort of event driven ( state machine ) type codes. And quite often the underlying engine may be implemented by others and sources are either unavailable or so large and complex that it really does not help much than to get us painfully bogged down into it. So how exactly we do coding for debugging in these situations?

(1) make sure that your defines for the states are as logically grouped as possible, and keep them in a data structure with the corresponding meaningul name of the event. For example of a window code ...

typedef struct Win_Events{

int  _EventConst;

char * _EventName;

};

Now you define an array of such structures (if you know the maximum number of events), or you can use a dynamic allocations.

(2) Write your state machine logic in a way so that you know what events you are not tackling by tracing those events in the unhandled cases. Some time state machines are coded using 'switch' statements of c/c++/java/c# and they can be nested to 3 or 4 levels. In each level of nesting one should use the 'default:'  label to ones advantage for such tracing. 

When I look at code for inspection, I look for these sort of things that are easy to forget, but essential to defensive programming. Unless these things are in place, it is very hard to debug these types of codes that are mostly event driven.