RE: Naming Global Variables

Kurt Anderson wrote on 12/12/2006 11:01:43 AM:

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. 

Yeah - I do something similar.  Most of our PFs have field names with 
prefixes already, so I just use 'sc' as the prefix for the screen field 
but leave the rest the same.  It seems to work fairly well, but it would 
be nice when reading the mainline for it to be obvious which procedures 
may mess around with screen fields, hence the desire to pass them into 
procedures in a chunk.  I know I could make a DS with all of the screen 
fields as subfields, but that's *way* more typing than I'd like to do. 
Hmmm ... it just occurred to me that I could probably use an externally 
defined DS.  I'll have to give that a shot.  I've been trying it out with 
some PFs on my current project and I'm quite liking the technique.

 

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.

Okay - I thought that was probably what you were referring to.  I usually 
do some calcs in the main, as well as call some procedures (both within 
the module and in other reusable modules).  I'd be interested to read 
these articles, because I'd like to know what happens if there is a fatal 
error in one of these procedures.  Unless there is some error handling in 
the mainline, it seems like it might be difficult to handle those errors 
gracefully.

#####################################################################################
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
#####################################################################################