I just have one all purpose test program called BBB (BBBecause it's easy to remember AND type)
This way when I test something, I just put in a STOP above the previous test stuff and then stick my new statements above that. This way if I ever need to go back and see if I tested a snippet of code that is close to what I need, I can just look at all the code and see. This has saved me a bunch o' hours through the years in that I never have to think of a unique name for a test program, and it becomes a historical record of programming examples that come in quite handy. I always like to have an AEE.BP file for my utilities, as well as a XXX.BP file for the clients files with the XXX being replaced with client's initials. The Manage-2000 system that I've worked a lot with has SCADS of .BP files for all the different modules and one gets used to seeing 6 pages of .BP's when listing the voc.......... I agree with you that having a bunch of .bp's with upgrade and upgrade.new is WAY more than scary and just outright sloppy. I am a firm believer in the XXX.BP and OBSOLETE.BP. This way obsolete code gets deleted from the XXX.BP and put into the OBSOLETE.BP and there is no question of what it is, and yet it's a real timesaver to be able to go back to OBSOLETE.BP and resurrect a function that the client said was dead, and then half a year later wants to know what happened to the function! I always make the OBSOLETE.BP a file, instead of a directory, and that prevents anyone from compiling any of the programs in it. I use the XXX.BP as I have had clients running multiple companies with different versions of the same code (like AP.CHECK printing) for their different divisions and yet they want the names to stay the same for ease of use. It's just another safeguard when copying and installing programs that you can see you're copying the CPI version of a program into the CPI.BP file instead of just a BP file which could have been in the RED account or the CPI account. Just my couple of pennies on this subject.........:) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Wednesday, October 20, 2004 17:18 To: [EMAIL PROTECTED] Subject: Re: [U2] [UD] running a subroutine True, but don't throw the baby out with the bathwater. If the program gets sophisticated enough that starts using COMMONS or INCLUDES, then write a real test program. Perhaps 90% of standard stupid test programs can be eliminated with PRINT. When I get a new client, I suggest and allow myself time to clean up BP items that I deem useless. I see BP items called TEST, TEST2, DATE, DATETEST, BOB, BOB1 etc that all exist for testing little things. Same with the MD (VOC). If the programmer wants to have a test program library, don't use the standard application library. Thus when people like me get involved, I don't have to wade through the little programs that may or may apply. I'm actually with a multi-programmer client now that has enlisted me to create some programming rules and disciplines. I've got a pretty good list of my favorites and am open for some more ideas from anyone else. My categories will not cover programming standards. I'm specifically attempting to enforce some naming rules for programs and/or files, as well as documenting changes and how to archive program changes short of a whole revision system. I dare not venture into the actual code. I just don't like a BP file littered with prior versions of programs like UPDATE.OLD, UPDATE.HOLD, UPDATE.TEMP, UPDATE.NEW, UPDATE.OLD.NEW etc. I will stand on my soapbox and declare these residual source records as being lazy and thoughtless. The original program, UPDATE, hopefully still is the real version. When I see UPDATE.NEW, I want to strangle someone as they now deviated from a sane naming convention and then their next revision will be UPDATE.NEW2 or UPDATE.NEW.NEW (I'm not kidding. I've seen this crap everywhere). Then there's UPDATE.OLD or UPDATE.OLD2 which is OK as long as none of those suffixed versions are on line. If they're obsolete, move them to another file so SEARCH or FIND doesn't gather them. I've seen every variation of these suffixes and know that my research will be that longer to weed through the false positives. Sorry for my soapbox. I just like a nice & tidy BP file. P.S. Don't flame me for the name UPDATE. I'm being concise with a functional name. ----- Original Message ----- From: "Stu Glancy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 20, 2004 12:49 PM Subject: Re: [U2] [UD] running a subroutine > Criticisms for Mark: > > Your concept won't work if there are commons that need to be set in the > calling program. However, with the use of named commons they can be set > in a test program and then use your print which includes the "$INCLUDE > file named.commons" in the command line. (For those who don't know, > named commons remain in memory between programs and can be used again > until you logout.) > > > > Bill H. wrote: > > >Mark: > > > >The program at http://www.pickwiki.com/cgi-bin/wiki.pl?BPTest doesn't even > >have these limitations. > > > >This wiki has some pretty nice free programs. I like to take the non-mvDbms > >attitude: it's free so use it. :-) We should all post our free programs > >there. > > > >Bill > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson > >>Sent: Wednesday, October 20, 2004 5:54 AM > >>To: [EMAIL PROTECTED] > >>Subject: Re: [U2] [UD] running a subroutine > >> > >> > > > >[snipped] > > > > > > > >>In fact, I welcome any criticisms or limitations anyone would have against > >>establishing this PRINT command to handle everything. I know of 2 > >>limits: 1) > >>No hanging ELSE or THENs. 2) Cannot use READNEXT. Other than that I'm all > >>ears. > >> > >>My 3 cents. > >> > >>----- Original Message ----- > >>From: "Peter Olson" <[EMAIL PROTECTED]> > >>To: <[EMAIL PROTECTED]> > >>Sent: Tuesday, October 19, 2004 8:43 AM > >>Subject: RE: [U2] [UD] running a subroutine > >> > >> > >> > >> > >>>"but i want more!" > >>> > >>>found it! > >>> > >>>0001: PQ > >>>0002: HSELECT > >>>0003: H EVAL "SUBR(' > >>>0004: A\2 > >>>0005: H', > >>>0006: A3 > >>>0007: H )" FROM VOC FIRST 1; > >>>0008: P > >>> > >>>now it's > >>> > >>>tcl>TS AGE.DATE -2224,42 > >>> > >>>Cool.... thanks! > >>> > >>> > >------- > >u2-users mailing list > >[EMAIL PROTECTED] > >To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [EMAIL PROTECTED] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
