Re: Module source naming schemes

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.

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?

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.


Regards,

Jim Langston

Scott Klement wrote:
> 
> I generally pick a 5-char name for each module in a service program that
> ends with "R4" to designate that I wrote it in RPG IV.
> 
> Then I start each procedure with the first 3 chars of that module name
> (everything but the R4).    This way, when I see a procedure being called,
> I know where to look for the source code for that procedure.
> 
> Example...  I have a library of routines for Finished Goods Inventory
> in a module called FGIR4.   The procedures are called things like
> "fgi_open"  "fgi_remove"  "fgi_slot"  "fgi_close", etc.
> 
> The "prototype member" which I often use for other things such as
> named constants relating to the procedures in the service program,
> I end with a "_H" to signify that its a header member.   (i.e. FGI_H)
> This is mainly because I'm used to ".h" files in C -- at any rate, it
> seems as good as any other method.
> 
> Generally I'd also name the actual service program "FGIR4", as well.  I
> have not yet needed to bind more than module into a single service
> program...   If I had many related service programs or modules, I could
> always put them in a binding directory.
> 
> Instead of the 'F', 'N', 'C' values that you suggest, I prefer to have
> something like  netf_open, netf_read, and netf_close procedures.  I find
> that more intuitive, somehow.
> 
> Thats my 2 cents...
> 
> On Mon, 8 Jan 2001, Jim Langston wrote:
> 
> > I'm starting to build module source files, which I compile then
> > create a service program with.  Each module source file will have
> > a prototype file.
> >
> > What type of a naming scheme should I have?
> >
> > I have some functions that would serve one application called Cartage,
> > so I'm thinking along the lines of CARTAGEMOD and CARTAGEPR for those.
> > Or should I go with MODCARTAGE and PRCARTAGE ?
> >
> > And then I have some general utilities, such as my StampToHHMM and
> > StampToCYMD routines, which take date/time stamps as input and return
> > hours and minutes, or CCCCYYMMDD. Should I make a separate module for
> > these and call it, what, MODDATTIM or DATTIMMOD ?
> >
> > Then I have one called RtvNetF which will Retrieve a user's list of
> > waiting network files one at a time ('F' for first call, 'N' for next
> > call, 'C' to close and set on LR).  What would I call this one?  MODSYSTEM
> > or SYSTEMMOD ?
> >
> > And then I want to stick this whole thing in one service program, which
> > I would call, what, ICSSERVICE ?
> >
> > What naming schemes has everyone else settled on?  So far there are no
> > modules on the system at all, nor are there any service programs, so 
>whatever
> > naming schemes I start with we will most likely go with.
> >
> > Any suggestions appreciated.
> >
> > Regards,
> >
> > Jim Langston
> 
> +---
> | 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
> +---
+---
| 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
+---