Hi David, I guess we'll have to just disagree on this point as I see our definition of a "single task" as being different. Although Basic can be treated as an object oriented environment, I do not think the majority of basic programmers do that, but that's just my unconfirmed belief.
I'll let you keep the (approximately) 10-line rule in your standards and I'll assume you'll let me keep it out of mine. Thanks. BobW > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-u2- > [EMAIL PROTECTED] On Behalf Of David A. Green > Sent: Tuesday, September 27, 2005 3:15 PM > To: u2-users@listserver.u2ug.org > Subject: [ ] - RE: [U2] Good Programming Practice Question......... - > Found word(s) list error in the Text body > > Bob, > > 10 lines is a good rule to live by. There are some exceptions like the > Initialization routine or large CASE structures that have many options. > But > the problem you run into if you don't restrict your lines is you end up > doing more than one thing. Most of the Pick programming that I've run > across has the subroutines going on and on and on. > > Making your subroutines short and precise is a good exercise in good > programming practices. In Object Oriented Programming we are taught that > more than 3 lines are too much. > > Here is an sample program: > > PROGRAM RUN.GUIDE > * DAG Consulting -- WWW.DAGCONSULTING.COM > * David A. Green -- 5/2/01 > * > * > EQUATE TRUE TO 1, FALSE TO 0 > EQUATE CLR TO @(-1) > ! > DEBUG.FLAG = TRUE > ! > GOSUB INIT > GOSUB PRINT.SCREEN > GOSUB OPEN.FILES > ! > IF NOT(ABORT.FLAG) THEN > LOOP > GOSUB SELECT.RECORDS > IF TOT.CNT THEN > LOOP > READNEXT VOC.KEY ELSE DONE.FLAG = TRUE > UNTIL DONE.FLAG DO > GOSUB READ.REC > IF OK.FLAG THEN GOSUB OPEN.FILE > IF OK.FLAG THEN GOSUB LOCKFILE > IF OK.FLAG THEN GOSUB PROCESS.REC > IF OK.FLAG THEN FILEUNLOCK F.FILE > REPEAT > END > GOSUB END.LOOP.LOGIC > WHILE LATER DO REPEAT > END > ! > GOSUB PRINT.TOTALS > ! > STOP > ! > END.LOOP.LOGIC: > END.CNT += 1 > IF END.CNT > 10 THEN ;* Give up after 10 trys, write the > remainder to a list. > PRINT "Max tries exceeded, remainder written to list RUN.GUIDE" > WRITELIST LATER ON "RUN.GUIDE" > LATER = "" > END ELSE > IF LATER THEN > SLEEP 10 > FORMLIST LATER > END > END > RETURN > ! > SELECT.RECORDS: > IF SYSTEM(11) THEN > TOT.CNT = SYSTEM(11) > END ELSE > CMD = "SSELECT ":FNAME:" WITH F1 = 'F'" > PERFORM CMD CAPTURING BUFF > TOT.CNT = @SYSTEM.RETURN.CODE > END > RETURN > ! > READ.REC: > READ VOC.REC FROM F.VOC, VOC.KEY THEN > OK.FLAG = TRUE > END ELSE > WAR.CNT += 1 > OK.FLAG = FALSE > PRINT "Warning: File ":DQUOTE(VOC.KEY):" NOT found in VOC!" > END > RETURN > ! > OPEN.FILE: > OPEN VOC.KEY TO F.FILE ELSE > ERR.CNT += 1 > OK.FLAG = FALSE > PRINT "Can't open ":DQUOTE(VOC.KEY):"!" > END > RETURN > ! > LOCKFILE: > OK.FLAG = TRUE > FILELOCK F.FILE LOCKED GOSUB LOCKED.FILE > RETURN > ! > LOCKED.FILE: > OK.FLAG = FALSE > LATER<-1> = VOC.KEY > PRINT "Will try ":DQUOTE(VOC.KEY):" later, file in use." > RETURN > ! > CHECK.CRITERIA: > SELECT.OK = TRUE > * > * Add Selection Criteria Here if Necessary > * IF VOC.Dict.Name = "" THEN SELECT.OK = FALSE > * > RETURN > ! > PROCESS.REC: > PRO.CNT += 1 > PRINT VOC.KEY:"..." > CMD = "!guide ":VOC.KEY > GOSUB DO.CMD > CMD = RENAME.CMD:" GUIDE_ADVICE.LIS ":VOC.KEY:"_GUIDE_ADVICE.LIS" > GOSUB DO.OS.CMD > CMD = RENAME.CMD:" GUIDE_ERRORS.LIS ":VOC.KEY:"_GUIDE_ERRORS.LIS" > GOSUB DO.OS.CMD > CMD = RENAME.CMD:" GUIDE_STATS.LIS ":VOC.KEY:"_GUIDE_STATS.LIS" > GOSUB DO.OS.CMD > CMD = RENAME.CMD:" GUIDE_FIXUP.DAT ":VOC.KEY:"_GUIDE_FIXUP.DAT" > GOSUB DO.OS.CMD > RETURN > ! > DO.CMD: > PERFORM CMD CAPTURING BUFF > RETURN > ! > DO.OS.CMD: > PCPERFORM CMD CAPTURING BUFF > RETURN > ! > INIT: > VOC.REC = "" > ABORT.FLAG = FALSE > DONE.FLAG = FALSE > FNAME = "VOC" > TITLE = "Running guide" > TOT.CNT = 0 > PRO.CNT = 0 > ERR.CNT = 0 > WAR.CNT = 0 > LATER = "" > END.CNT = 0 > * > ** OS Specific Settings > * > OS.TYPE = SYSTEM(33) > BEGIN CASE > CASE OS.TYPE = "UNIX" ; RENAME.CMD = "mv" ; FILE.SEP = > "/" > CASE OS.TYPE = "Windows NT" ; RENAME.CMD = "RENAME" ; FILE.SEP = > "\" > CASE 1 ; RENAME.CMD = "mv" ; FILE.SEP = > "/" > END CASE > RETURN > ! > PRINT.SCREEN: > PRINT CLR:TITLE > RETURN > ! > OPEN.FILES: > ONAME = "VOC" ; OPEN '', ONAME TO F.VOC ELSE GOSUB OPEN.ERROR > RETURN > ! > OPEN.ERROR: > PRINT "Can't open ":DQUOTE(ONAME) > ABORT.FLAG = TRUE > RETURN > ! > PRINT.TOTALS: > COL.WIDTH = LEN(TOT.CNT); COL.FMT = COL.WIDTH:"R" > PRINT > PRINT "Total Records : ":TOT.CNT COL.FMT > PRINT "Total Processed : ":PRO.CNT COL.FMT > PRINT "Total Errors : ":ERR.CNT COL.FMT > PRINT "Total Warnings : ":WAR.CNT COL.FMT > RETURN > ! > END > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bob Woodward > Sent: Tuesday, September 27, 2005 1:30 PM > To: u2-users@listserver.u2ug.org > Subject: RE: [U2] Good Programming Practice Question......... > > I agree with Kevin, specifically for the reasons he mentions, but I > actually prefer using the alpha-numeric format like S3000.GET.CUSTNAME: > where the "S" designates it's an internal subroutine, "3000" is the > numeric position value that Kevin talks about, and "GET.CUSTNAME" so > every place that I call the subroutine from, I know what I'm looking to > do in that subroutine. I also put the colon ":" so when I want to > actually go to that subroutine in the editor, I can. The numeric > portion is in relation to the whole program, not just the "S" portion. > This keeps me from accidentally doing a A3000 instead of an S3000. > > I do have to disagree with the statement of 10-line subroutines, though. > Limit them to one function, okay, but limit the number of lines? Not > even as a guideline in my list of standards. > > BobW > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:owner-u2- > > [EMAIL PROTECTED] On Behalf Of Kevin King > > Sent: Tuesday, September 27, 2005 1:04 PM > > To: u2-users@listserver.u2ug.org > > Subject: RE: [U2] Good Programming Practice Question......... > > > > And here's where the conflict begins. When looking through a big > > program, I much prefer numeric labels in order with comments vs. > > alphanumeric labels. With numeric labels in order you find 1800 and > > if you're looking for 2000 you know to look farther down, 1000, go up. > > With alpha labels if you find SELECT.FILE and are looking for > > UPDATE.FILES, you have nothing but experience to know whether to look > > up or down from there. > > > > Numeric labels are good. Not ordering or commenting them is bad. And > > not putting comments around all labels to make them more easily > > distinguished from the rest of the program is near unforgiveable. > > > > -K > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Allen E. > > Elwood > > Sent: Tuesday, September 27, 2005 12:40 PM > > To: u2-users@listserver.u2ug.org > > Subject: RE: [U2] Good Programming Practice Question......... > > > > My addition to this would be to use alphanumeric labels, and to *have* > > a main calling section. A main calling section that looks like: > > > > GOSUB OPEN.AND.INIT > > GOSUB SELECT.FILE > > GOSUB PRE-PROCESS.VALIDITY.CHECKS > > GOSUB PRINT.INVOICES > > GOSUB UPDATE.FILES > > > > Looks so much better and is so easier to figure out than > > > > GOSUB 100 > > a bunch of statements > > a bunch of statements > > a bunch of statements > > GOSUB 1250 > > a bunch of statements > > a bunch of statements > > a bunch of statements > > GOSUB 1375 > > a bunch of statements > > a bunch of statements > > a bunch of statements > > GOSUB 4000 > > a bunch of statements > > a bunch of statements > > a bunch of statements > > GOSUB 9755 > > a bunch of statements > > a bunch of statements > > a bunch of statements > > > > IMNSHO - *=aee=* > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of George Gallen > > Sent: Tuesday, September 27, 2005 12:12 > > To: u2-users@listserver.u2ug.org > > Subject: RE: [U2] Good Programming Practice Question......... > > > > > > Also, how about a change log at the top of the program > > that lists, who, when and what/why a change was made. > > > > add to that a short description as to what the function > > of the program is for. > > > > * this program does ..... > > * > > * > > * date who changes made > > * date who changes made > > ******************************************** > > * > > > > George > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Dianne > > Ackerman > > Sent: Tuesday, September 27, 2005 2:57 PM > > To: u2-users@listserver.u2ug.org > > Subject: Re: [U2] Good Programming Practice Question......... > > > > > > I like these and would add another one - Add comments to > > tricky-looking code! > > -Dianne > > > > David A. Green wrote: > > ------- > > 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/ > > > > -- > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.344 / Virus Database: 267.11.7/112 - Release Date: > > 9/26/2005 > > ------- > > 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/ > ------- > 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/
