Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
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


List of 29 messages in thread
TopicAuthorDate
Uart user menu via switch/case state machine            01/01/70 00:00      
   State machine can be small.            01/01/70 00:00      
   My take....            01/01/70 00:00      
   asked and answered            01/01/70 00:00      
      Broken and Fixed            01/01/70 00:00      
         excellent            01/01/70 00:00      
            My experience as well....            01/01/70 00:00      
               My experience as well....            01/01/70 00:00      
               But you're the writer...            01/01/70 00:00      
                  out of context            01/01/70 00:00      
                     Yes, Chances are no one else will see your code            01/01/70 00:00      
                        male cow manure            01/01/70 00:00      
                           Don't be too over confident            01/01/70 00:00      
                  Just Concepts            01/01/70 00:00      
                     Don't think own code is the best            01/01/70 00:00      
                     exactly            01/01/70 00:00      
                        what I have done a lot of lately is            01/01/70 00:00      
   Protothreads???            01/01/70 00:00      
   A case for a CASE tool?            01/01/70 00:00      
      Using a tool like that........            01/01/70 00:00      
         Thanks Michael...            01/01/70 00:00      
            Pencil and paper            01/01/70 00:00      
      Pros and Cons            01/01/70 00:00      
         Analysis/Design            01/01/70 00:00      
            Enterprise Architect            01/01/70 00:00      
               RE: Enterprise Architect            01/01/70 00:00      
                  Reverse State Tables            01/01/70 00:00      
                     RE: "Reverse-engineering"            01/01/70 00:00      
                        php and html when documenting            01/01/70 00:00      

Back to Subject List