??? 07/02/10 15:57 Read: times |
#177068 - My take.... Responding to: ???'s previous message |
David -
There are as many ways to implement these things as there are programmers that implement them. That said I think that the best method of implementation is that which leaves the code with these three considerations: 1) is straightforward to maintain and understand, 2) is easy to extend or take away from, 3) works best for the persons involved with working on it. In my opinion you should not get hung up on certain "rules" that have been promoted in the industry. I see no problem making source files as large as they need to be to capture the modularity and functionality of the program in a reasonable way. The idea of constraining a source to a "screen or two" is an old fashioned idea stemming back to old days where systems used character mode RS232 terminals, limited memory development systems, command line text editors and debugging from printed listings. With the types of tools available today and the fact that debugging can be completed to finished product without ever having to make a printed copy there is no reason to constrain the source code to arbitrary metrics that make life more difficult. If you need modularity consider this. Most menu systems are somewhat hierarchical in nature and will exhibit a top level and subsequent "lower" levels. You could implement your system as a series of source files that capture each of the various lower levels as their own mechanism. The top dispatch mechanism can even be a separate logic block in its own source file that knows how to launch each of the various lower level modules. I've used this latter scheme to good advantage at times where one can give the user more direct access to various menu branches without having to force a walk back up the menu structure to the top level. Consider for example a product that has a top level menu function that has selection functions for "Calibrate", "Run", "Print" and "Setup". These could be menu driven as well as having front panel buttons for each function to launch the various sub-functions. A separate top level dispatcher makes this modular and easy to implement. Michael Karas |