Re: Module source naming schemes

On Tue, 9 Jan 2001, Jim Langston wrote:

> Scott,
> 
> Yeah, I'm not happy with the 'F' 'N' and 'C' myself.  I am contemplating,
> and probably will, go into the //copy member for this and create some 
>constants.
> RNF_Open 'F'
> RNF_Next 'N'
> RNF_Close 'C'
> 
> One thing I have found irritating when I code this is that I only need the
> first two parameters when I first call this thing.  And every other time I
> actually don't need any parameters at all if used from a first to last 
>situation,
> and I really don't even think I have to set on LR for this thing, since it's
> in activation group *Caller anyway.  And if you wanted a new set and passed it
> the 'F' again it would resetup the pointers.

Thats why I make them seperate procedure calls, the parameters that you
need to "start the list" are rarely the same parms that you need when
"getting each entry".   I'd use rnf_open, rnf_read and rnf_close.   I
use this system mainly because all programmers are familiar with the
open/read/close concept -- so they see it as "easy to incorporate".   

Even if you don't need a "close" right now, I've found that its a good
idea to have the procedure, and tell programmers to call it.   The reason
is because even if you don't need it now, eventually -- as your program
gets changed/improved -- you'll have things that need to be done at
"cleanup time".   When that happens, you'll be happy that you've already
got a procedure thats being called by all the programs that use your
service program...

> 
> So, all I really need to know is if it's the first time or not, and if
> it is the first time, what the username and system name are.  Hmm..
> perhaps 2 calls then.
> 
> RtvNetFIni(UserName, SysName)
> RtvNetFNxt()
> 
> The question then becomes, how do I define my variables so that both
> RtvNetFIni and RtvNetF can see them?  I am thinking if I declare them
> at the top of the source file outside any functions they will be
> global to that source file, and any module contained in it, right?  
> But not visible to other programs, such as the RPG program.
> 
> Is this correct?

Yes, this is correct.  (Unless you do an "activation group export", which
I always discourage people from using)

> In which case, since they are global, I would want to define them as
> RNF_Data
> RNF_Options
> RNF_Lib
> RNF_Idx
> 
> My naming scheme for global variables (ones seen outside one program
> or function) is three letters designating the function they are from,
> and underscore and their name.
> 

Hmmmm...  I personally use this system (the function designation, followed
by the var name) for variables/constants/functions that are available from
"outside of the service program", rather than "outside of a function".

I use "wk" ("work") as a prefix to a variable name for variables that are 
global to my module, but do not affect anythng outside of it, and I use
"ww" (which, I guess, stands for "workwork"... but ww is just easy to
type) for variables that are local to a subprocedure.  I also use a "pe"
prefix for parameters... etc, etc.

In your case, if I had named constants like error numbers, or something,
I'd start THOSE with RNF_ and put them in the header...

Of course, that's just how I'd do it, for informational purposes only.  :)
I wish you luck on developing a standard that makes sense to you.



+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---