I often program report generating data/basic programs that will have a final prompt that says "Type S=Screen or P=Printer" and the user can view the report likewise.
Thus, I program that entire report with PRINT and let their answer dictate whether it's under PRINTER ON or not. BTW regarding styles and tricks I've learned. The MSG application has the variable for the aforementioned question as SORP for Screen OR Printer. I continue to use that variable for this method. Given the mess of spaghetti that I've inherited with incredible inconsistency, I feel good using consistent variable names, record names, file handle syntaxes and label names/numbers. (No flames please on label numbers. Sometimes the words get wordy) I'll toss about another 'style' preference. I like to open files with a consistent name (no flames on named commons, too hard to install downstream). I use F.INVENTORY or D.INVENTORY for the data or dict level respectively. While there are no rules for file handle names, I personally don't care for variable names that are not indicative of being a file handle. For example: OPEN "INVENTORY" TO F.INVENTORY OPEN "INVENTORY" TO INVENTORY.FILE OPEN "INVENTORY TO FILE.INVENTORY OPEN "INVENTORY TO INVENTORY.F OPEN "INVENTORY TO INV.F are all indicative of the variable name being a file handle. (Again no flames please on the use of periods or capital letters) Having OPEN "INVENTORY" TO INVENTORY or OPEN "INVENTORY" TO INV is very confusing downstream. Also, within an application, I would like the filenames to be consistent and the same. The 5 line examples are all taken from a client's system that has had 2 prior programmers propogating more than 2 styles. Pathetic. Plus, when I do a FIND or SEARCH to see what programs use which files, it gets tricky as I would have to scan for quote INVENTORY or double-quote INVENTORY. One method that appeals to me but it hard to backfill into an existing app is to have the file opened, dimensioned array created and the field names equated in a single include. Thus, the entire app would be using the file handles, dimensioned array names and the alias equates consistently named (by insistence of the includes) and be much easier to read and learn. The Primac applications do that. Since most of my apps are the evolved result of an endless parade of prior programmers, I inherit their 'styles' and move forward with my own. I have yet to run into an example (except Primac) whereby I continue with a prior style. If I'm adding to the confusion by introducing another style, I remind myself that I am the current cook in the kitchen and new programs will have my style and as time allows, changes to existing programs will be done in my style. Sometimes it's easier to re-write the entire program instead of trying to understand someone's stupid style. My 2 cents. Mark Johnson ----- Original Message ----- From: "Anthony W. Youngman" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Friday, March 16, 2007 3:49 AM Subject: Re: [U2] Reports In Universe BASIC > In message <[EMAIL PROTECTED]>, Kevin King > <[EMAIL PROTECTED]> writes > >From: MAJ Programming > >>Like helping the newbies with MV, I can now add this > >>little tidbit to my mental library of techniques > >>should the need arise. > > > >Just because one can doesn't mean one should. In the case of PRINT ON > >working properly without a corresponding PRINTER ON, imagine six > >months later trying to find all of the programs that are outputting to > >the printer. Not only do we have to search for procs and paragraphs > >that start the program with a (P (or LPTR) option, but now in > >searching through the BP code we have to search for both PRINTER ON > >and PRINT ON. It's likely that someone will forget one of those > >options (and possibly a few others I may have missed in this quick > >post) and overlook a program that should have otherwise been found. > > But if it's your default style ALWAYS to use PRINT ON, then you won't > forget it. Yes, I know there's loads of old code ... > > But using PRINT ON is sometimes necessary (printing several reports from > one pass of the data), and prevents errors with PRINTER ON. Oh - and if > you're going to go down your route, I'd enforce a style that said "PRINT > always prints to the printer, if you want the terminal, use CRT". That > was the style used by a colleague of mine. > > So we had a real mix :-) Old stuff with PRINTER ON, my colleague using > CRT for the terminal, and me using PRINT ON. I take your point, but > these techniques are useful. > > Cheers, > Wol > -- > Anthony W. Youngman <[EMAIL PROTECTED]> > 'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the > thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man > lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998 > Visit the MaVerick web-site - <http://www.maverick-dbms.org> Open Source Pick > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
