|
<snip> What I'm referring to is some articles I've read about making the main nothing but calls to procedures, which I personally don't generally do. </snip> I don't like this just the same as I don't like the "main" procedure using nothing but subroutines (just a personal pet peeve of mine). Even if it works as designed, it makes maintenance more difficult than it has to be (especially using SEU). Thanks, Tommy Holden -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Kurt Anderson Sent: Tuesday, December 12, 2006 10:02 AM To: RPG programming on the AS400 / iSeries Subject: RE: Naming Global Variables We use the F-spec prefix on display and printer files so those fields are easily distinguishable. I think it works pretty well for our shop. Also, since I'm not a fan of having field names in a dspf or prtf that is the exact same name as a file field name, I never run into that situation.
How would you structure a main() without any logic? What if one of the procedures you call in your main has an error? Maybe I'm misunderstanding.
Yeah, error checks *whistles innocently*... While I do monitor for errors (invalid date into a date field, converting an alpha to numeric, etc), I usually deal with them from within procedures. I don't know what exactly you're really referring to. What I'm referring to is some articles I've read about making the main nothing but calls to procedures, which I personally don't generally do. Kurt Anderson Application Developer Highsmith Inc -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of AGlauser@xxxxxxxxxxxx Sent: Tuesday, December 12, 2006 8:24 AM To: RPG programming on the AS400 / iSeries Subject: RE: Naming Global Variables Kurt Anderson wrote on 12/12/2006 08:44:28 AM:
Right now when I have a constant I try to either make it all caps and use an underscore between words, or I do something like LBL_OrderNum (which could contain a screen label). The idea of prefixing with a lower case c is appealing to me. Possibly the g as well for globals.
I also use your current method of all caps for constants.
I know the use of global variables should be limited, and normally they are. If it's a good day my only globals are logic control of the
main (which could arguably have no logic control) and RRNs.
How would you structure a main() without any logic? What if one of the procedures you call in your main has an error? Maybe I'm misunderstanding. If your only globals are logic control and RRNs, does that mean you don't do many programs involving screen or printer files? I've been trying to figure out a good way of passing all of the screen variables around between procedures so that, while they are technically global variables, they can look less like globals. Does anyone have any good ways of doing this? Thanks for starting an interesting discussion, Adam ######################################################################## ############# Attention: The above message and/or attachment(s) is private and confidential and is intended only for the people for which it is addressed. If you are not named in the address fields, ignore the contents and delete all the material. Thank you. Have a nice day. For more information on email virus scanning, security and content management, please contact administrator@xxxxxxxxxxxx ######################################################################## ############# -- This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpg400-l or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.