Standards of the dUFLP Library
                           (written by Jay Parsons)

        The purpose of this library is to assist programmers using the dBASE 
language, preferably users of the Borland dBASE products.  Contributions of 
neat ways to do new things, better ways to do old things or just handy routines
are earnestly requested.  Once accepted, all such routines are considered placed
in the public domain, but support from the contributor will be appreciated and 
may be requested.

        In order to make the library as useful as possible, please have your 
contributions adhere to the following standards, which are goals more than 
rules:

        Modularity - Contributions should be of procedures or functions that 
can be used, as far as possible, in any context within the versions of dBASE
for which written.  Where use of external global variables or files opened 
before calling the routine is inevitable, the routine header should specify the
required environment.

        Style - Please use the header form, styles of capitalization and naming
of variables and other conventions set forth in DHUNG2.ZIP (on COMPUSERVE's
dBASE Forum, Library 4). This makes it much easier for readers of items 
contributed from different sources to find the information they need; it may 
also be required by library-management programs to assure the inclusion of 
called routines in files to which the calling routines are copied.

        Encapsulation - Routines that can reasonably operate without changing 
any external variables, active windows, etc., without printing to the screen, a
printer or a file and without changing any dBASE "SET" items should do so.  
ALL VARIABLES CREATED WITHIN A ROUTINE SHOULD BE "PRIVATE", AND ALL PARAMETERS 
LEFT UNCHANGED, to keep changes made within from affecting the outside world.  
Any departures from complete encapsulation, such as opening or closing files, 
input, output, changing "SET" items or work areas should be noted in the header. 
This does not mean a routine should not change such items, but that if it does,
it should restore them to the starting status if it reasonably can.  This 
standard is necessarily subjective.  One of the nicer routines ( CURRPORT() ) in 
this release is a workaround for the failure of dBASE IV 1.5 to contain a 
printerset() function to report what file or device PRINTER is SET to, without 
which it cannot be reset on exit.  The workaround routine is complex and slow 
enough that it may be preferable simply to note in the header of a routine 
using printer redirection that the routine changes the setting, leaving it to 
users to add the code needed to detect the original setting and restore it if 
it matters to them. 

        Error handling - There is generally no need to handle errors such as 
calling a routine with the wrong number or type of parameters.  This can be 
left to the calling program or dBASE itself.  Handling errors with screen 
displays of messages, prompts for reentry of data, etc. is sufficiently complex
that this too can usually be left to dBASE or the calling program. However, in 
no case should a function return a value as an error code that might be 
mistaken for a valid result, such as 0 for the average of numbers in an array 
if there are no such numbers or array.  Something available to the calling 
routine after the return should be provided that will, if inspected by the 
calling routine, give it notice that an error has occurred.  And, of course, 
the manner in which the calling routine should check for an error should be
documented in the header if not obvious.

        Planning ahead - The library contains many fine routines that are 
somewhat obsolete.  If contributing one for the future, try to anticipate 
changes.  A center() function that takes a string of characters and prints it 
in the middle of an 80 x 25 screen is nice, but one that also takes the width 
and returns the string padded with blanks on the left or both ends to the given
width is probably better, because it supports use with screens of other widths
or heights, printing the resulting string to a file and other variations.  This
too is subjective, as anticipating unlikely contingencies will require extra 
and slowing code.

        This is your library.  Enjoy it, contribute what you can, and please 
report any bugs or other unexpected results to:

                        Ken Mayer ( CIS: 71043,3232 )
                        Programmer and Librarian