|
<Snip> from reeve (deep breath) What bothers me about this kind of solution is that additional logic is being introduced to control program flow. Yes, CABxx and CASxx meld logic and branching, but I'd consider their (let's include ITER, LEAVE, and LEAVESR in the grouping) use to be in the second order of complexity while a simple GOTO is the first order of complexity. Understanding how a SELECT group works is not intuitive. Scott's solution is an excellent template. However, logic is not required to figure out what GOTO means, and in the interest of discussing the presenting problem in isolation, I'm assuming a given program's coding technique did not include a side order of marinara. </Snip> I have been working in a shop that has code from 25 years ago. IMHO the goto's represent a big problem in this code. Once you use one goto it is very hard to avoid using another goto without re-coding the previous goto(s). This perpetuates 'Spaghetti Code' that is difficult to maintain. With For, DOW, DOU loops and standardized good programming practices, "RPG IV Style Revisited" by Bryan Meyers, this problem is virtually eliminated. I admit there is a learning curve for those that are not fluent with this style of coding. When I picked programming as a profession, I knew that education would be a continuing part of my career. When something new comes along, (or in this case something tried and proven) we need to analyze the benefits that it can give us and use it to its best functionality. <Snip> from reeve My application package, currently running 900,000 lines of RPG in 1,500 application programs (there's a lot of reusable code), features a large number of application panels individually supported by a unique help panel and a combination of standard and panel-specific command keys. I've done a fair amount of white-board and back-of-the-envelope scribbling to figure out a "better" way that works for the application and for what my customers expect; so far, my standard template with "just enough" GOTO's (exclusively for display file management) holds up well. Program flow is a key part of any business application, and I'd suggest it's just as important as the user interface design and the editing/processing functions. </Snip> Again we are dealing with different styles here. I would have to say mine is better (VBG - I'm not stuck on myself at all). I believe that all code should be short and modularized. That keeps logic reusable and easy to group. Again, there is a learning curve to doing ILE. I feel this form of programming saves time and makes it easier to maintain. (Instead of several locations to change certain logic such as retrieving an Items price, you only have to change one service program) Bryan K. Merrell (The GOTO Hater) bkmerrell@xxxxxxxxxxxxxxx You can't argue taste, religion, politics, or application development. In fact, application development is a superset that includes the other three, which makes it very dangerous indeed. Timothy Pricket Morgan - MidrangeServer.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.