                     Standards of the dUFLP Library
                        (written by Jay Parsons
                     and tinkered with by Ken Mayer)

        The purpose of this library is to assist programmers using the 
dBASE language, preferably users of the dBASE, Inc. 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, functions,
custom controls, forms, etc. 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.TXT
(available as part of the dUFLP package). This makes it much easier 
for readers of items contributed from different sources to find the 
information they need. Please keep all lines of both documentation and 
code to 70 characters or less. This makes it easier to post code 
on the internet from the library ...

        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.  

        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.
   In addition, keep in mind that dBL includes the try/catch structure,
   and some error handling can be performed in your code if you feel
   it is necessary.

        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 the librarian,
and/or use the codelib newsgroup provided by dBASE, Inc.


Specific Requests:
  1) Use spaces, rather than tabs. Also, please, for consistency, use
     3 spaces for your indents if at all possible.
  2) Always end your macros with a dot (&macroname.)
  3) Set your margin to 70 characters maximum for both your documentation
     and your code.
  4) Do not assign a value to a macro as:
     &macro. = <value>
       The compiler will choke on this. Instead, use:
     store <value> to &macro.
  5) Please use the header AS SHOWN the end of DHUNG2.TXT included
     with this library. 

=======================================================================
NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE

     In order to keep the dUFLP library working in a manner that
     helps the users, we have decided to create separate
     versions of the library. 

     ---------
     The DOS versions of the library may be gone ... I don't know 
     if the Compuserve forums even still exist. 

     ---------

     The Visual dBASE 5.5 version of the dUFLP library can be 
     found on Compuserve at: 
        VDBASE
        File Name: LIW55B.ZIP

     And it can also be found at my web site:
        http://www.goldenstag.net/dbase

     As can the Visual dBASE, dB2K and dBASE Plus versions of the
     library.

=======================================================================

