Re: [U2] Good Programming Practice Question.........
I do like your use of the word 'strategy'. That probably better defines a programmer's approach to solving any particular problem, especially given the diverse environments one may encounter. Mark Johnson - Original Message - From: Timothy Snyder [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, October 02, 2005 4:59 AM Subject: Re: [U2] Good Programming Practice Question. Mark Johnson [EMAIL PROTECTED] wrote on 10/01/2005 01:00:33 AM: Files that can't open are usually solved pretty quickly either after installing the software or making the changes. The downstream elaborate errmsgs for OPEN CUSTOMER TO F.CUSTOMER ELSE PRINT CANNOT OPEN THE CUSTOMER FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP OPEN INVENTORY TO F.INVENTORY ELSE PRINT CANNOT OPEN THE INVENTORY FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP or whatever the verbose message/mechanism is, is just an exercise in typing. 99.44% of the time the ELSE clause is not realized. So because it's not likely that an open will fail, it's not worth programming for? Can you guarantee that the files will never be placed on a network or external device that could fail? Or that the file could be deleted or otherwise rendered unusable? I realize that 99.44% is a reference to an old Ivory Soap ad, but imagine 56 opens out of 10,000 failing - that would certainly be worth coding for. Even if there's one chance in a million that an open will fail, that's worth coding for. I cringe when I see OPEN ... ELSE STOP 201, 'WIDGET'. (I've also even seen it with just STOP, without even referencing the file name.) That means the poor user will be placed at the command prompt with no idea of what to do. (And, noting that you advocate doing OPENs in external subroutines, that could leave transactions partially committed. Even if performance isn't a concern for you, this should be enough justification to avoid that practice.) I worked with a customer once that had just installed UniData with RFS. Everything went well through months of development and testing. Then, on the first day running live, OPEN statements started hitting their ELSE clauses. It turned out that the N_AFT parameter hadn't been set high enough. For those not familiar with RFS, suffice it to say that there wasn't enough space in a table that maintains open recoverable files, causing the opens to fail. Fortunately, that customer had some intelligence built into their open routines, which logged the problems and got the users out fairly gently. One strategy that I like is to have the ELSE clause add the file name to a list. Then after all of the opens have been attempted, see if the list is empty - if not, report on the files that couldn't be opened, log them somewhere, and get the user back to a safe point such as a menu. It may require a bit of typing, but those few keystrokes seem well worth the effort. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- 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/
Re: [U2] Good Programming Practice Question.........
Mark Johnson [EMAIL PROTECTED] wrote on 10/01/2005 01:00:33 AM: Files that can't open are usually solved pretty quickly either after installing the software or making the changes. The downstream elaborate errmsgs for OPEN CUSTOMER TO F.CUSTOMER ELSE PRINT CANNOT OPEN THE CUSTOMER FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP OPEN INVENTORY TO F.INVENTORY ELSE PRINT CANNOT OPEN THE INVENTORY FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP or whatever the verbose message/mechanism is, is just an exercise in typing. 99.44% of the time the ELSE clause is not realized. So because it's not likely that an open will fail, it's not worth programming for? Can you guarantee that the files will never be placed on a network or external device that could fail? Or that the file could be deleted or otherwise rendered unusable? I realize that 99.44% is a reference to an old Ivory Soap ad, but imagine 56 opens out of 10,000 failing - that would certainly be worth coding for. Even if there's one chance in a million that an open will fail, that's worth coding for. I cringe when I see OPEN ... ELSE STOP 201, 'WIDGET'. (I've also even seen it with just STOP, without even referencing the file name.) That means the poor user will be placed at the command prompt with no idea of what to do. (And, noting that you advocate doing OPENs in external subroutines, that could leave transactions partially committed. Even if performance isn't a concern for you, this should be enough justification to avoid that practice.) I worked with a customer once that had just installed UniData with RFS. Everything went well through months of development and testing. Then, on the first day running live, OPEN statements started hitting their ELSE clauses. It turned out that the N_AFT parameter hadn't been set high enough. For those not familiar with RFS, suffice it to say that there wasn't enough space in a table that maintains open recoverable files, causing the opens to fail. Fortunately, that customer had some intelligence built into their open routines, which logged the problems and got the users out fairly gently. One strategy that I like is to have the ELSE clause add the file name to a list. Then after all of the opens have been attempted, see if the list is empty - if not, report on the files that couldn't be opened, log them somewhere, and get the user back to a safe point such as a menu. It may require a bit of typing, but those few keystrokes seem well worth the effort. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
I use a subroutine called OPENER that spares me (any anyone else who uses it) all of the verbose typing that is so cluttering in every program. I'm not ignoring the ELSE clause. I'm just referencing the vast amount of coding for such a small percentage of it being needed. My OPENER is as follows: SUBROUTINE OPENER(FILENAME, FILEHANDLE) OPEN FILENAME TO FILEHANDLE ELSE Do whatever you want in the world for an ELSE. Notify the user. Log the transgression. Chain back to the menu. STOP 201, FILENAME Logoff I don't really care. END RETURN Just put all of the 'war peace' stuff once, I repeat *ONCE* in the sub instead of in the thousands of OPEN statements in the thousands of application programs. I'm was not suggesting OPEN FILE ELSE STOP blindly. Just spare yourself from all the typing and me from all the reading 10 years from now when I get to the program. The only time I don't use OPENER is if I want to manage the ELSE condition such as creating new files on the fly or processing something for the first time the file is missing. That's the 56/100 % I was referring to. The 99 44/100's of the time it's just a regular OPEN. I also did mention its value when first installing on a new environment. Yes, it also works as CALL OPENER(DICT CUSTOMER, D.CUSTOMER) and with all the D3 comma'd files. I wouldn't have offered it (nor would have Spectrum printed an article about it) if it wasn't universally helpful. Thanks Mark Johnson - Original Message - From: Timothy Snyder [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sunday, October 02, 2005 4:59 AM Subject: Re: [U2] Good Programming Practice Question. Mark Johnson [EMAIL PROTECTED] wrote on 10/01/2005 01:00:33 AM: Files that can't open are usually solved pretty quickly either after installing the software or making the changes. The downstream elaborate errmsgs for OPEN CUSTOMER TO F.CUSTOMER ELSE PRINT CANNOT OPEN THE CUSTOMER FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP OPEN INVENTORY TO F.INVENTORY ELSE PRINT CANNOT OPEN THE INVENTORY FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP or whatever the verbose message/mechanism is, is just an exercise in typing. 99.44% of the time the ELSE clause is not realized. So because it's not likely that an open will fail, it's not worth programming for? Can you guarantee that the files will never be placed on a network or external device that could fail? Or that the file could be deleted or otherwise rendered unusable? I realize that 99.44% is a reference to an old Ivory Soap ad, but imagine 56 opens out of 10,000 failing - that would certainly be worth coding for. Even if there's one chance in a million that an open will fail, that's worth coding for. I cringe when I see OPEN ... ELSE STOP 201, 'WIDGET'. (I've also even seen it with just STOP, without even referencing the file name.) That means the poor user will be placed at the command prompt with no idea of what to do. (And, noting that you advocate doing OPENs in external subroutines, that could leave transactions partially committed. Even if performance isn't a concern for you, this should be enough justification to avoid that practice.) I worked with a customer once that had just installed UniData with RFS. Everything went well through months of development and testing. Then, on the first day running live, OPEN statements started hitting their ELSE clauses. It turned out that the N_AFT parameter hadn't been set high enough. For those not familiar with RFS, suffice it to say that there wasn't enough space in a table that maintains open recoverable files, causing the opens to fail. Fortunately, that customer had some intelligence built into their open routines, which logged the problems and got the users out fairly gently. One strategy that I like is to have the ELSE clause add the file name to a list. Then after all of the opens have been attempted, see if the list is empty - if not, report on the files that couldn't be opened, log them somewhere, and get the user back to a safe point such as a menu. It may require a bit of typing, but those few keystrokes seem well worth the effort. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- 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/
Re: [U2] Good Programming Practice Question.........
I think there is such thing as good practice. But it is not an MV good practice. The rules of good programming practice are the same in any programming language. But not all languages allow the programmer to follow all the rules. And some programming languages force the programmer to follow some of the rules while others allow to do whatever the developer feels like doing. Serguei - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, September 30, 2005 3:22 AM Subject: Re: [U2] Good Programming Practice Question. There's no such a thing as MV standards. Period. Personal standards, yes. VAR standards, yes. MV Standards, absolutely none. This thread, while starting on noble grounds of 'good' programming practices, will eventually turn into a pissing contest of implied standards. My 1 cent. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
The one you don't understand what it is doing when you see it for the first time. - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, September 30, 2005 3:55 AM Subject: Re: [U2] Good Programming Practice Question. Define tricky looking code. Thanks. - Original Message - From: Serguei Poliakov [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, September 29, 2005 5:09 AM Subject: Re: [U2] Good Programming Practice Question. I thinks the better to say - if the code looks tricky, there is something wrong with it. The advice would be - don't write tricky-looking code. :) Serguei - Original Message - From: Dianne Ackerman [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 7:56 PM 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: I've been teaching UniBasic for over 10 years and here are some of the methods I teach: * Subroutines should only have one job. * Subroutines should be short. (less than 10 lines) * Subroutines should have one entrance and one exit. * Use meaningful variable names and subroutine names. * Be consistent in your naming conventions. * Don't hard code Numbers, Strings, or Attributes. * Use CASE over IF...THEN when there are more than two options. * Use LOOP...WHILE/UNTIL...REPEAT over FOR...NEXT with IF Conditions. * Use REMOVE to traverse a dynamic array. * Use a Simple Variable on Conditional Statements. * Use UniData Internal Variables whenever possible; i.e. @AM, @VM, @DATE. Thank you, David A. Green DAG Consulting (480) 813-1725 www.dagconsulting.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fawaz Ashraff Sent: Tuesday, September 27, 2005 8:23 AM To: u2-users@listserver.u2ug.org Subject: [U2] Good Programming Practice Question. Hi All, We are planning to train some of our new programmers to use good programming practices when using U2 Basic. I can remember in Unidata days us having some tech support documents that talked about this. Example such as when is the best time to use CASE instead IF ELSE or not to use GOTO statments. I am sure some of you may have some input in this topic. If you have some documents, notes or thoughts on this, can you please share with us? When I get all the technical tips, I can compile this to a document and share with our new programmers as well as U2 listserver community. Thanks Mohamed --- 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/
Re: [U2] Good Programming Practice Question.........
Sometimes, if a subroutine is only called during certain situations (thus, not often) and the file used by the subroutine is not used by the main program, opening the file within the subroutine that uses it makes sense to me. - From: Mark Johnson [EMAIL PROTECTED] What's the real need to have OPEN's in a sub. Isn't the main purpose of subs to allow repeated access of the same code. What's wrong with top-down coding with the OPENs, INCLUDES and other housekeeping in the beginning. I also think that any programming to accomodate the hardware limitations of the past should stay in the past. Dartmouth and other interpeted Basic languages were proven that code nearer to the top executed faster. So be it. I can't imagine that a sub anywhere in a program is any 'closer' to the top runs noticably faster. You would be hard pressed in a 60-100 user environment with everyone running their variety of apps to notice a provable difference in your program. Academic at best. I just inherited a job costing app that is a bear to debug. It 'reads' well with its graceful GOSUBs for everything but it gets out of hand. BTW, I wish the data/basic debugger would not 'step' through called subs when stepping through the main program. Just curious. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
One thing that has been over-looked in this conversation is the notion of 'lowest common denominator programming'. My software runs on all MV platforms. Therefore, whenever possible, I stick with syntax that works on all platforms. When that is not possible, I resort to calls and includes and CASE statements. Sometimes the syntax that works on ALL platforms is not the clearest, the most modern or the fastest to execute on any given platform. But so far I've not been able to justify having multiple versions of code *that are not necessary*. For example, I don't use alpha labels because they will not compile on all versions / flavors. Same with the REMOVE logic because it doesn't fly on all platforms. Both of those are handy and have benefits -- but are not worth keeping up with a separate version of the code for. Some things there is no common method -- things like the CHANGE() command, SWAP, RAISE, LOWER, CONVERT) ... I have to have a different subroutine/include/chunk to run this on each platform. Another nickel in the ante. Susan --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Fair enough. Mark Johnson - Original Message - From: Serguei [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, September 30, 2005 4:29 AM Subject: Re: [U2] Good Programming Practice Question. The one you don't understand what it is doing when you see it for the first time. - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, September 30, 2005 3:55 AM Subject: Re: [U2] Good Programming Practice Question. Define tricky looking code. Thanks. - Original Message - From: Serguei Poliakov [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, September 29, 2005 5:09 AM Subject: Re: [U2] Good Programming Practice Question. I thinks the better to say - if the code looks tricky, there is something wrong with it. The advice would be - don't write tricky-looking code. :) Serguei - Original Message - From: Dianne Ackerman [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 7:56 PM 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: I've been teaching UniBasic for over 10 years and here are some of the methods I teach: * Subroutines should only have one job. * Subroutines should be short. (less than 10 lines) * Subroutines should have one entrance and one exit. * Use meaningful variable names and subroutine names. * Be consistent in your naming conventions. * Don't hard code Numbers, Strings, or Attributes. * Use CASE over IF...THEN when there are more than two options. * Use LOOP...WHILE/UNTIL...REPEAT over FOR...NEXT with IF Conditions. * Use REMOVE to traverse a dynamic array. * Use a Simple Variable on Conditional Statements. * Use UniData Internal Variables whenever possible; i.e. @AM, @VM, @DATE. Thank you, David A. Green DAG Consulting (480) 813-1725 www.dagconsulting.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fawaz Ashraff Sent: Tuesday, September 27, 2005 8:23 AM To: u2-users@listserver.u2ug.org Subject: [U2] Good Programming Practice Question. Hi All, We are planning to train some of our new programmers to use good programming practices when using U2 Basic. I can remember in Unidata days us having some tech support documents that talked about this. Example such as when is the best time to use CASE instead IF ELSE or not to use GOTO statments. I am sure some of you may have some input in this topic. If you have some documents, notes or thoughts on this, can you please share with us? When I get all the technical tips, I can compile this to a document and share with our new programmers as well as U2 listserver community. Thanks Mohamed --- 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Sometimes, if a subroutine is only called during certain situations (thus, not often) and the file used by the subroutine is not used by the main program, opening the file within the subroutine that uses it makes sense to me. One problem with that Susan - what happens if the file doesn't exist or can't be opened for some reason? I realise that this isn't exactly common, but it was always the prime reason given to me for opening all files first before any processing takes place. Col. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Susan, You make a good point, but the problem with that approach is that it stifles innovation and learning - though not in your case, of course :-) I have known programmers who took a 'lowest common demoninator' approach that was based on systems that were obsolete 20+ years ago, ignoring useful constructs because possibly they weren't supported on McDonnell Douglas Reality kit back when they were learning - or more likely, because their first manager told them not to use them because (s)he had heard they weren't supported 10 years earlier still. We accuse IBM of not doing enough in RD, and then refuse to use the tools they do provide for lack of compatibility (just how many UV houses out there actually USE the SQL or transactional functionality?) I would rather say, be aware of the differences and isolate them ... (In my case, I code in UniVerse as the widest feature set and use a precompiler to handle the differences) Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Joslyn Sent: 30 September 2005 13:17 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Good Programming Practice Question. One thing that has been over-looked in this conversation is the notion of 'lowest common denominator programming'. My software runs on all MV platforms. Therefore, whenever possible, I stick with syntax that works on all platforms. When that is not possible, I resort to calls and includes and CASE statements. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Serguei wrote: The one you don't understand what it is doing when you see it for the first time. I like that .. but it might instead be the algorithm that is hard to understand if you're not familiar with it. E.g the first time you see a parser 's central loop you're not likely to grasp it. But if you've understood the algorithm and the code still doesn't make sense emediately, then -- mats --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
And your SOX auditors haven't had a cow over that practice? Ours about died from apoplexy when they saw all the archive stuff in our production file. The only thing allowed in the production file are the programs currently in production. We were forced to create a non-compilable archive file to hold these outdated versions of programs. But the auditors still dictated that we maintain version history within the source code as well. rant Everyone of you that does not reside in the USA can thank your lucky stars you don't have to deal with the absurdity of Sarbanes/Oxley. Which by the way, does nothing to prevent the kinds of things that went on at Enron. Nice job congress! /rant Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 09/29/2005 10:41:04 PM: I agree with Jeff's disagreement. In my travels, I'll inherit a program that may have had 1-10 prior programmers on it. That means nothing to me now. I'm the current cook in the kitchen and for all it matters, all of their 'mods' could have been written when the program was originally written. The only good thing is recognizing personal patterns (their standards) so I can think like them when the time comes. I have a useful method of protecting the past and staying sane for the future. If I'm working on BP UPDATE, I copy it to BP UPDATE_092905, never to be compiled or used again. Then the BP UPDATE is mine to clean up (Remove all the useless mod commentsand tighten up old-school ideas) and viola, sometimes (most of the time) the code is that much more readable. Next week, when I need to make some more changes, I copy to BP UPDATE_100505 and so forth. [Snip] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
FOR X = 1 TO PROMPT.CNT *some code here* *Back up one prompt* X = X - 1 - (X # 1) NEXT X Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 09/29/2005 10:55:26 PM: Define tricky looking code. Thanks. [snip] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
The first programming book I read called this the: Shirley Temple Principle - i.e.. Don't' get too cute. It provided an example of a multi-line If-Then-Else construct compressed into one line. Strangely enough it kind of looked like some f-correlatives I've seen. Colin Alfke Calgary, Canada -Original Message- From: Mark Johnson Define tricky looking code. Thanks. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
It is recommended that the extra variable be create to prevent unnecessary machine cycles. It was considered a good programming practice when we were using Prime computers back in the mid 1980's. The explanation was that every iteration of the FOR / NEXT loop caused the cpu to calculate the ending value. The DCOUNT was executed on every iteration. Setting this value to a variable, did the calculation once. It may not seem like much, but when you have large arrays and a large number of records to process, this makes very good sense. Rich Samamrtino At 10:27 AM 9/29/2005 +0100, you wrote: Why do you need to create an extra variable (LAST)? It only make sense if the number of elements in ARRAY is really big. If you expect it to have 1 to 10 elements an extra variable only makes your code more difficult to maintain. On REMOVE I completely agree with you - it just makes it more difficult to understand the code without giving anything in return. - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 10:46 PM Subject: Re: [U2] Good Programming Practice Question. Another good suggestion: Use: LAST=DCOUNT(ARRAY,CHAR(253)) FOR I=1 TO LAST blah NEXT I instead of FOR I=1 TO DCOUNT(ARRAY,CHAR(253)) I know that REMOVE is pretty promoted here but most times I use a FOR/NEXT loop because I don't want to maintain a separate mv variable for using any other associated attributes. My 1 cent. - Original Message - From: Keith W. Roberts [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 5:14 PM Subject: RE: [U2] Good Programming Practice Question. I most heartily agree! Numbers in the labels don't elucidate; they merely increase the length. And I'm pretty sure I know that U comes somewhere after S. :) My $0.02 (on issues ancillary to the code itself) ... - make your BP files Type19 (DIR), so you can edit them outside of U2 using whatever cotton-pickin' editor you like - use source code control; absolutely anything is better than nothing, and there are good free ones for all platforms - agree on an indentation scheme and stick to it as a group, else get/create a beautifier which enforces the chosen standards before code checkin -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill_H Sent: Tuesday, September 27, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[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=* --- 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
RE: [U2] Good Programming Practice Question.........
I agree. Subroutines should be of a reasonable size for the task to be performed, but to limit by lines is really unnecessary. In fact it can lead to a over-use of subroutines (yes there is such a thing) that creates very fragmented code. I was guilty of this in a sizable utility and it became a real bear to debug and enhance. 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 Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. The more they complicate the plumbing the easier it is to stop up the drain - Montgomery Scott NCC-1701 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Taylor Sent: Friday, September 30, 2005 7:53 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. I would add a few: 1) no multi-command lines (i.e. command ; command; command Generally speaking, I agree. But there are places where it actually enhances readability. For example, in front of a section of code you initialize a set of counters to 0, or a set of arrays to ''. Stacking them together keeps more program real estate visible on the screen. But I'm of two minds on this one myself. :) A better example is a short set of cases where they all set a variable or two and do a GOSUB. [snip] 4) No MATREAD MATWRITE. Some will probably disagree, but to me this takes a wonderfully dynamic system and hamstrings it. I have also seen data corruption happen when you have a large file dictionary than the array dimension. This is definitely platform dependant though. Unidata just puts all remaining fields into the last array position. If you then change that position expecting it to be just the one field you want to work with, the remainder of the data is lost. Universe behaves differently, but I still don't think using these commands is a good idea. Yes, this is application-dependent. If the app is bottle-necked because of huge dynamic arrays (like invoices with hundreds of line items can be), then MATREAD/WRITE can give you an order of magnitude better performance. Generally, I have always had three general rules that I apply up front. All the specific standards created work to support those three rules. 3) The code must be maintainable. Proper structure, NO use of the 'command-that-must-not-be-named' Well, there's at least *one* valid use for a GOTO ... :) Let's say you define a common in an INCLUDE. You need to initialize it somewhere, and I don't like separat init routines, because there's too much chance of them getting out of synch. So I embed an init GOSUB at the end of the INCLUDE. Since it's embedded (and that's the *only* case one should be embedded) you need to GOTO a label after the sub's RETURN. -Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Absolutely! But if you obey the rule that a statement should have only one purpose, you will never, ever attempt to write that on one line. :) Oh, and one other thing ... I despise constructs like: IF (expr) ELSE do.something which can *always* be written more clearly as: IF NOT(expr) THEN do.something Which is why I *never* create a flag like NOT.whatever ( I also hate double negatives :). -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Gallen Sent: Friday, September 30, 2005 10:35 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. BUTYou have to be careful that what is on the line doesn't have an ELSE clause of it's own which is optional..(ie. WRITE). IF (COND) THEN WRITE SOMETHING ON F.FILE,ID ELSE RELEASE F.FILE,ID which needs to be IF (CONT) THEN WRITE SOMETHING ON F.FILE,ID END ELSE RELEASE F.FILE,ID END I remember once trying to figure out why my locks were never being released, if compiled with the ELSE as a clause of then WRITE, and the IF with no ELSE clause at all (This was on a Prime, but I don't take chances anymore). George -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Keith W. Roberts Sent: Friday, September 30, 2005 1:19 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. I don't mind if-then-else on one line ... as long as it fits on one *screen* line. :) IF SOME.FLAG THEN GOSUB DO.SOMETHING ELSE GOSUB DO.SOMETHING.ELSE -Keith --- 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/
RE: [U2] Good Programming Practice Question.........
C'mon! How difficult *is* it with your editor to convert it to block format when either clause becomes multi-line?!? -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: Friday, September 30, 2005 10:51 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. I don't mind if-then-else on one line ... as long as it fits on one *screen* line. :) IF SOME.FLAG THEN GOSUB DO.SOMETHING ELSE GOSUB DO.SOMETHING.ELSE And I'm completely opposite, preferring a full block IF statement all the time. There's four different ways that IF can be structured, and the full block structure provides the most flexibility for maintenance (in my opinion, of course). Yeah, it takes more lines, but it's fewer lines to change when an inline IF ends up getting converted to the partial or full block format, and it's been my experience that comparison programs get more accurate results with insertions and deletions vs. changed lines. -K --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
C'mon! How difficult *is* it with your editor to convert it to block format when either clause becomes multi-line?!? Difficulty isn't the issue, easily differentiating what was changed in source history is the issue. When an single line IF is converted to a block IF there is a change to a line and additional insertions. When starting with the block if from the start, if more needs to be done based on the conditional there is insertions without the change to the original line. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith W. Roberts Sent: Friday, September 30, 2005 12:23 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. C'mon! How difficult *is* it with your editor to convert it to block format when either clause becomes multi-line?!? -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: Friday, September 30, 2005 10:51 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. I don't mind if-then-else on one line ... as long as it fits on one *screen* line. :) IF SOME.FLAG THEN GOSUB DO.SOMETHING ELSE GOSUB DO.SOMETHING.ELSE And I'm completely opposite, preferring a full block IF statement all the time. There's four different ways that IF can be structured, and the full block structure provides the most flexibility for maintenance (in my opinion, of course). Yeah, it takes more lines, but it's fewer lines to change when an inline IF ends up getting converted to the partial or full block format, and it's been my experience that comparison programs get more accurate results with insertions and deletions vs. changed lines. -K --- 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.9/115 - Release Date: 9/29/2005 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Exception to no multi-command lines. TOT(1,1)=0; TOT(1,2)=0; TOT(1,3)=0; TOT(1,4)=0; * Resets array for this loop And as far as no MATREADS/WRITES. You can always INCLUDE the DIM statements. Which can also include the equates for standardized variable names for each attribute. And yeah, you'd have to recompile every program when new attributes are added. But as others will point out, if you're updating a lot of attributes, there are performance advantages. Roger Richard Taylor wrote: I would add a few: 1) no multi-command lines (i.e. command ; command; command 2) Use Continue and Exit inside loops to handle error conditions. 3) I then to prefer the following for working with select lists LOOP WHILE READNEXT ITEM.ID DO Some commands REPEAT 4) No MATREAD MATWRITE. Some will probably disagree, but to me this takes a wonderfully dynamic system and hamstrings it. I have also seen data corruption happen when you have a large file dictionary than the array dimension. This is definitely platform dependant though. Unidata just puts all remaining fields into the last array position. If you then change that position expecting it to be just the one field you want to work with, the remainder of the data is lost. Universe behaves differently, but I still don't think using these commands is a good idea. Ok, let the flame war begin. 5) Proper variable names; no single character variables, variable names should indicate there purpose. 6)INDENT YOUR CODE. This may be obvious to most here, but I have worked with programmers that seem to have a phobia about this. Generally, I have always had three general rules that I apply up front. All the specific standards created work to support those three rules. 1) A program must work. By that I mean that it solves the client's problem and gives them what they need. It is NOT simply that the program was syntactically or even logically correct. 2) The code must be readable by any one. Indentation, comments, variable names are things that support this. 3) The code must be maintainable. Proper structure, NO use of the 'command-that-must-not-be-named' One other thought, since you are talking about new programmers. You will likely need to train them on proper testing/debugging technique. The basic mistake I see many programmers make in testing is that they test to see that it works. What you should be doing is trying to break it! Lord knows the users will. That is my $0.02 such as it is. Rich Taylor | Senior Programmer/Analyst| VERTIS 250 W. Pratt Street | Baltimore, MD 21201 P 410.361.8688 | F 410.528.0319 [EMAIL PROTECTED] | http://www.vertisinc.com Vertis is the premier provider of targeted advertising, media, and marketing services that drive consumers to marketers more effectively. The more they complicate the plumbing the easier it is to stop up the drain - Montgomery Scott NCC-1701 --- 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/
RE: [U2] Good Programming Practice Question.........
Brian, When you say pre-compiler ... tell me ... drooling ... have you written something that combs through BASIC code to highlight platform specific syntactical differences? My fantasy is to build an engine and then to build a small database of the commands (strings) as key that don't work or don't work the same on all platforms ... so that I can add to the database over time as I convert to new platforms or new features are added etc. Have you headed down that sort of road? SJ - -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach Sent: Friday, September 30, 2005 8:18 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Susan, You make a good point, but the problem with that approach is that it stifles innovation and learning - though not in your case, of course :-) I have known programmers who took a 'lowest common demoninator' approach that was based on systems that were obsolete 20+ years ago, ignoring useful constructs because possibly they weren't supported on McDonnell Douglas Reality kit back when they were learning - or more likely, because their first manager told them not to use them because (s)he had heard they weren't supported 10 years earlier still. We accuse IBM of not doing enough in RD, and then refuse to use the tools they do provide for lack of compatibility (just how many UV houses out there actually USE the SQL or transactional functionality?) I would rather say, be aware of the differences and isolate them ... (In my case, I code in UniVerse as the widest feature set and use a precompiler to handle the differences) Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Files that can't open are usually solved pretty quickly either after installing the software or making the changes. The downstream elaborate errmsgs for OPEN CUSTOMER TO F.CUSTOMER ELSE PRINT CANNOT OPEN THE CUSTOMER FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP OPEN INVENTORY TO F.INVENTORY ELSE PRINT CANNOT OPEN THE INVENTORY FILE. PLEASE CONTACT YOUR PROGRAMMER. PROGRAM TERMINATING ; STOP or whatever the verbose message/mechanism is, is just an exercise in typing. 99.44% of the time the ELSE clause is not realized. My 1 cent. - Original Message - From: Colin Jennings [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, September 30, 2005 9:00 AM Subject: Re: [U2] Good Programming Practice Question. Sometimes, if a subroutine is only called during certain situations (thus, not often) and the file used by the subroutine is not used by the main program, opening the file within the subroutine that uses it makes sense to me. One problem with that Susan - what happens if the file doesn't exist or can't be opened for some reason? I realise that this isn't exactly common, but it was always the prime reason given to me for opening all files first before any processing takes place. Col. --- 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/
Re: [U2] Good Programming Practice Question.........
Is compression bad? One could debate the intracicies of when to use multi-line IF-THEN-ELSE and when to keep it as one line. My 1 cent - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, September 30, 2005 9:38 AM Subject: RE: [U2] Good Programming Practice Question. The first programming book I read called this the: Shirley Temple Principle - i.e.. Don't' get too cute. It provided an example of a multi-line If-Then-Else construct compressed into one line. Strangely enough it kind of looked like some f-correlatives I've seen. Colin Alfke Calgary, Canada -Original Message- From: Mark Johnson Define tricky looking code. Thanks. --- 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/
Re: [U2] Good Programming Practice Question.........
CONTINUE and EXIT have greatly reduced the addition of labels to continue or exit from loops. Kudos. Like I mentioned before. There is no and never will be such a thing as MV programming standards. VAR-level or individual-level of course. But not even UV, UD, D3 or a whole platform can create or enforce standards. Period. Even if we factor out the 20+ year old legacy code or the hardware limited code and focus only one one pure MV flavor, say UD, and get the best heads together to conclude on 'standards', they won't be able to be 100% consistent. Not to mention the 4GL's like SB, Eclipse and others. That's the great thing about standards, there's so many to choose from. My 1 cent. Mark Johnson - Original Message - From: Louis Windsor [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, September 30, 2005 9:40 AM Subject: Re: [U2] Good Programming Practice Question. I second the motion. Just throw everything into a pot and leave it to each person's taste. I find some of the ideas suggested ludicrous but that's my opinion. I generally prefer numeric labels (in strict sequence) with each label meaning something. e.g. Label 800 is where every data entry program goes after ALL fields are entered. Label 900 is the Page Heading routine. Label 950 is the Page Heading routine if more than one report is output. These standards suit me and my employer. If they don't suit you then that's your problem not mine! I work on ONE system (currently HP Unix) running UniVerse And I LOVE LOOP WHILE READNEXT ID Some code IF needs be THEN CONTINUE ELSE EXIT REPEAT No EOF variables, no loop indicators. Self explanatory. No labels. If you don't like it don't use it! I have written entire programs without any labels and programs with labels. You show me how you can write a data entry block of code to allow entry of a field, validate it, allow the User the option to accept it, Go Back to the previous field, abort the whole session entered so far etc etc without labels. The input is really done through an input handling subroutine which sets a return variable after various validation routines. The return variable is addressed by a ON R GO 300,100,800 etc. Stop trying to impose YOUR standards on someone else. Just express your opinion and move on. My 3 cents worth. Putting on flame proof suit. Louis - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, September 30, 2005 8:38 PM Subject: Re: [U2] Good Programming Practice Question. : Kevin: : It happened already. One poster said that subs should be 10 lines or less. : That's his 'standard' and it works for him. It may not work for everyone. : : The back and forth on label nomenclature is another example. I use a mixture : of both numeric and alpha-numeric as my 'standard'. : : To answer your question, we all can contribute our own 'standards' and let : the reader decide which standard will become theirs. In programming, : especially in MV, there are many ways to solve the same problem. My : standards may offend others as theirs may offend me. So the request for : programming standards will inevitably cause conflict. : : I often get flames for my suggestions on this forum. That's fine. I'm used : to it. I guess that as long as my standards work for me and my clients, then : that's fine also. : : I knew from the onset of that innocent question it would become a popular : thread. Perhaps a compilation of the various methods for each MV element : could be made (or acquired) and each could pick (no pun intended) what they : like the most. : : Thanks : Mark Johnson : - Original Message - : From: Kevin King [EMAIL PROTECTED] : To: u2-users@listserver.u2ug.org : Sent: Thursday, September 29, 2005 11:13 PM : Subject: RE: [U2] Good Programming Practice Question. : : : This thread, while starting on noble grounds of 'good' programming : practices, will eventually turn into a pissing contest of implied : standards. : : I normally ignore you, but this one has me interested. Why must this : otherwise educational topic be degraded into implication? : : -K : --- : 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/
Re: AW: [U2] Good Programming Practice Question.........
- Another part of the application selects a record from the Invoice Detail file. It locks it for update and then locks the associated Order Header entry e.g. to adjust summaries. You could lock the header file first, and then lock the detail file to avoid this deadlock. --- Ewinger Klaus [EMAIL PROTECTED] wrote: When talking about lock management: Define a sequence in which you are updating the files of your application. If you do not take care of the sequence of your locks, you will most probably run into deadlocks. This is especially true when using transaction processing, as transactions increase the lifetime of locks. A typical scenario that is often seen in applications which is a source for deadlocks: - There are two files: Invoice Header and Invoice Detail - One part of the application updates an invoice from an entry screen. It locks the Invoice Header record first and the Invoice Detail record then. - Another part of the application selects a record from the Invoice Detail file. It locks it for update and then locks the associated Order Header entry e.g. to adjust summaries. - Bang! You've got your deadlock situation. -Urspr|ngliche Nachricht- Von: Michael Logue [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 27. September 2005 23:13 An: u2-users@listserver.u2ug.org Betreff: Re: [U2] Good Programming Practice Question. What about lock management? 1. Lock all records that are going to be updated ... even if the update is really a delete 2. Release your locks promptly (either with a RELEASE, WRITE or DELETE statement) - don't let the program termination be the time when record locks are released 3. Use the LOCKED clause so the application can decide what to do when a record is locked rather than the database P. Michael Logue U2 Technical Support Engineer U2 Products Service Planner IBM Certified Solutions Expert in U2 Application Development IBM Certified U2 UniData Administration IBM Information Management Division, Software Group Phone: 303-773-7846 Tie Line: 656-7846 Email: [EMAIL PROTECTED] www.ibm.com/software/data/u2/support Open, Query, Update, Search - Online! --- 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/ __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: AW: [U2] Good Programming Practice Question.........
There is no reason to lock details if the header is locked (you would not want two users to modify the same invoice). So the correct procedure is not to lock details at all. - Original Message - From: Dave S [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, September 29, 2005 2:51 PM Subject: Re: AW: [U2] Good Programming Practice Question. - Another part of the application selects a record from the Invoice Detail file. It locks it for update and then locks the associated Order Header entry e.g. to adjust summaries. You could lock the header file first, and then lock the detail file to avoid this deadlock. --- Ewinger Klaus [EMAIL PROTECTED] wrote: When talking about lock management: Define a sequence in which you are updating the files of your application. If you do not take care of the sequence of your locks, you will most probably run into deadlocks. This is especially true when using transaction processing, as transactions increase the lifetime of locks. A typical scenario that is often seen in applications which is a source for deadlocks: - There are two files: Invoice Header and Invoice Detail - One part of the application updates an invoice from an entry screen. It locks the Invoice Header record first and the Invoice Detail record then. - Another part of the application selects a record from the Invoice Detail file. It locks it for update and then locks the associated Order Header entry e.g. to adjust summaries. - Bang! You've got your deadlock situation. -Urspr|ngliche Nachricht- Von: Michael Logue [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 27. September 2005 23:13 An: u2-users@listserver.u2ug.org Betreff: Re: [U2] Good Programming Practice Question. What about lock management? 1. Lock all records that are going to be updated ... even if the update is really a delete 2. Release your locks promptly (either with a RELEASE, WRITE or DELETE statement) - don't let the program termination be the time when record locks are released 3. Use the LOCKED clause so the application can decide what to do when a record is locked rather than the database P. Michael Logue U2 Technical Support Engineer U2 Products Service Planner IBM Certified Solutions Expert in U2 Application Development IBM Certified U2 UniData Administration IBM Information Management Division, Software Group Phone: 303-773-7846 Tie Line: 656-7846 Email: [EMAIL PROTECTED] www.ibm.com/software/data/u2/support Open, Query, Update, Search - Online! --- 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/ __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com --- 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/
Re[2]: AW: [U2] Good Programming Practice Question.........
Serguei, Thursday, September 29, 2005, 8:04:07 AM, you wrote: S There is no reason to lock details if the header is locked (you would not S want two users to modify the same invoice). So the correct procedure is not S to lock details at all. '... So the correct procedure ...' G What problem does this cause? IF the locks are placed and removed correctly there is no problem. I would agree that it is easier to simply lock the header but only if you can guarantee that this will IN ALL SITUATIONS handle the entire set. Should be .. could be .. maybe .. Sometimes, as a consultant, I might do this (belt and suspenders) because of the state of the code and programming style that the 'employees' (monkeys) have exibited in the system does not give me any confidence that they will correctly respect lock 'sets' that way. dsig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: AW: [U2] Good Programming Practice Question.........
Are you talking about a specific application here or in general? - Original Message - From: Serguei [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, September 29, 2005 10:04 AM Subject: Re: AW: [U2] Good Programming Practice Question. There is no reason to lock details if the header is locked (you would not want two users to modify the same invoice). So the correct procedure is not to lock details at all. - Original Message - From: Dave S [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, September 29, 2005 2:51 PM Subject: Re: AW: [U2] Good Programming Practice Question. - Another part of the application selects a record from the Invoice Detail file. It locks it for update and then locks the associated Order Header entry e.g. to adjust summaries. You could lock the header file first, and then lock the detail file to avoid this deadlock. --- Ewinger Klaus [EMAIL PROTECTED] wrote: When talking about lock management: Define a sequence in which you are updating the files of your application. If you do not take care of the sequence of your locks, you will most probably run into deadlocks. This is especially true when using transaction processing, as transactions increase the lifetime of locks. A typical scenario that is often seen in applications which is a source for deadlocks: - There are two files: Invoice Header and Invoice Detail - One part of the application updates an invoice from an entry screen. It locks the Invoice Header record first and the Invoice Detail record then. - Another part of the application selects a record from the Invoice Detail file. It locks it for update and then locks the associated Order Header entry e.g. to adjust summaries. - Bang! You've got your deadlock situation. -Urspr|ngliche Nachricht- Von: Michael Logue [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 27. September 2005 23:13 An: u2-users@listserver.u2ug.org Betreff: Re: [U2] Good Programming Practice Question. What about lock management? 1. Lock all records that are going to be updated ... even if the update is really a delete 2. Release your locks promptly (either with a RELEASE, WRITE or DELETE statement) - don't let the program termination be the time when record locks are released 3. Use the LOCKED clause so the application can decide what to do when a record is locked rather than the database P. Michael Logue U2 Technical Support Engineer U2 Products Service Planner IBM Certified Solutions Expert in U2 Application Development IBM Certified U2 UniData Administration IBM Information Management Division, Software Group Phone: 303-773-7846 Tie Line: 656-7846 Email: [EMAIL PROTECTED] www.ibm.com/software/data/u2/support Open, Query, Update, Search - Online! --- 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/ __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com --- 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/
RE: [U2] Good Programming Practice Question.........
I understand the concept of tagging changed lines but this seems to suggest that deletions are commented out instead of removed. After four or five changes you get confused about what is executing and what isn't. I am a strong proponent of removing deleted lines of code. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Thanks a lot for all the input on this subject. Cheers Mohamed __ Yahoo! for Good Donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
My 1 cent on this. I like to pass as few items to subs as possible. If I inherit subs with file handles being passed, then so be it. My environments, typically 60 users or less, don't give me any grief when opening files in the subs. If I had 500 users then I may think differently. No flames please. I like testing subs at TCL and the external OPEN's get in the way. Mark Johnson - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, September 28, 2005 8:43 AM Subject: RE: [U2] Good Programming Practice Question. I may have missed someone else mentioning this, don't open files in an external subroutine that is called from within a loop. Yeah, yeah, I know you can set up a common, but isn't it cleaner to open the file in the main routine? Bruce M Neylon Health Care Management Group --- 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/
Re: [U2] Good Programming Practice Question.........
This thread, while starting on noble grounds of 'good' programming practices, will eventually turn into a pissing contest of implied standards. Will? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
I agree with Jeff's disagreement. In my travels, I'll inherit a program that may have had 1-10 prior programmers on it. That means nothing to me now. I'm the current cook in the kitchen and for all it matters, all of their 'mods' could have been written when the program was originally written. The only good thing is recognizing personal patterns (their standards) so I can think like them when the time comes. I have a useful method of protecting the past and staying sane for the future. If I'm working on BP UPDATE, I copy it to BP UPDATE_092905, never to be compiled or used again. Then the BP UPDATE is mine to clean up (Remove all the useless mod commentsand tighten up old-school ideas) and viola, sometimes (most of the time) the code is that much more readable. Next week, when I need to make some more changes, I copy to BP UPDATE_100505 and so forth. I absolutely despise the pathetic renaming of programs as UPDATE.V2, UPDATE.NEW, UPDATE.HOLD, UPDATE.TEMP, UPDATE.BKUP etc. Keep the run-time version called UPDATE and modify the archive version with the date suffix. I swear that I've seen live programs called NEW.UPDATE.TEMP.NEW. It gets pretty thesaurus-like with the different words for New and Old. The worse was ABRIDGED.UPDATE. One client's main cust maint is IMPROVED.CUSTMAINT.SUB.2. C'mon. If my methods can hurt me, then they haven't yet. Mark Johnson - Original Message - From: Jeff Schasny [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, September 28, 2005 11:55 AM Subject: RE: [U2] Good Programming Practice Question. I've got to disagree with this one. This is the job of your source code control system. I've seen applications which were commented in this manner over a number of years and they are almost unreadable due to the sheer volume of mod tags. -Original Message- [mailto:[EMAIL PROTECTED] Behalf Of Marilyn Hilb Sent: Wednesday, September 28, 2005 8:48 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Two items I have thought of. 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. [snip] --- 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/
Re: [U2] Good Programming Practice Question.........
I'm redundant in my prior post. Sorry. I would also suggest archiving BP UPDATE_092905 in separate file, BP.ARCHIVE for example. This way, a FIND (SEARCH) won't grab false positives when looking for a program. I wrote an article for Spectrum on this very topic. Mark Johnson - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, September 28, 2005 12:28 PM Subject: RE: [U2] Good Programming Practice Question. I'll second that motion. If you *really* want source control, get serious about it and save all previous versions with dates as part of the id. Then you can just do source compares if you need to go back a rev. When you get a 2300 line program, and 1700 of the lines have comments with project numbers and permission about who said to do it, the overhead to keep the revision history ***HARD CODED*** becomes 60% or more of the project. Let the computer do the work for you. Instead of hard coding revisions, keep a revision file! By saving the program before modifying it, it becomes 0.01% overhead, and a.fish.in.sea is the name of the game. Since I end up going back a revision, about once out of every 1500 programs I change, I don't think it's a great idea to obfuscate the code with Joe said this was ok 02-02-88 when Joe worked for the company 15 years ago and nobody even remembers who he was. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Schasny Sent: Wednesday, September 28, 2005 08:56 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. I've got to disagree with this one. This is the job of your source code control system. I've seen applications which were commented in this manner over a number of years and they are almost unreadable due to the sheer volume of mod tags. -Original Message- [mailto:[EMAIL PROTECTED] Behalf Of Marilyn Hilb Sent: Wednesday, September 28, 2005 8:48 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Two items I have thought of. 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. [snip] --- 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/
Re: [U2] Good Programming Practice Question.........
What's the real need to have OPEN's in a sub. Isn't the main purpose of subs to allow repeated access of the same code. What's wrong with top-down coding with the OPENs, INCLUDES and other housekeeping in the beginning. I also think that any programming to accomodate the hardware limitations of the past should stay in the past. Dartmouth and other interpeted Basic languages were proven that code nearer to the top executed faster. So be it. I can't imagine that a sub anywhere in a program is any 'closer' to the top runs noticably faster. You would be hard pressed in a 60-100 user environment with everyone running their variety of apps to notice a provable difference in your program. Academic at best. I just inherited a job costing app that is a bear to debug. It 'reads' well with its graceful GOSUBs for everything but it gets out of hand. BTW, I wish the data/basic debugger would not 'step' through called subs when stepping through the main program. Just curious. - Original Message - From: Gordon J Glorfield [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Cc: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org Sent: Wednesday, September 28, 2005 1:33 PM Subject: RE: [U2] Good Programming Practice Question. I prefer alphanumeric labels for subroutines. The label should give some clue as to the function of the subroutine. The subroutines should be in frequency of use order with the most commonly used closer to the top of the program. Subroutines that are used once in a program (file opens, variable initialization, etc...) are located near the bottom. This method is suppose to improve the efficiency of the program and may not be valid anymore. In the Sequoia version of Pick O/A it did matter. The run-time engine would start at the top of the program to search for a subroutine. Therefore a subroutine that was accessed over and over again would be found quicker each time if it was closer to the top. Some programmers even took this to an extreme by making the first line of a program read GOTO MAIN.LINE. The next line would be the label for the most commonly accessed subroutine. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 09/27/2005 04:35:12 PM: Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill [SNIP] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- 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/
Re: [U2] Good Programming Practice Question.........
Define tricky looking code. Thanks. - Original Message - From: Serguei Poliakov [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, September 29, 2005 5:09 AM Subject: Re: [U2] Good Programming Practice Question. I thinks the better to say - if the code looks tricky, there is something wrong with it. The advice would be - don't write tricky-looking code. :) Serguei - Original Message - From: Dianne Ackerman [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 7:56 PM 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: I've been teaching UniBasic for over 10 years and here are some of the methods I teach: * Subroutines should only have one job. * Subroutines should be short. (less than 10 lines) * Subroutines should have one entrance and one exit. * Use meaningful variable names and subroutine names. * Be consistent in your naming conventions. * Don't hard code Numbers, Strings, or Attributes. * Use CASE over IF...THEN when there are more than two options. * Use LOOP...WHILE/UNTIL...REPEAT over FOR...NEXT with IF Conditions. * Use REMOVE to traverse a dynamic array. * Use a Simple Variable on Conditional Statements. * Use UniData Internal Variables whenever possible; i.e. @AM, @VM, @DATE. Thank you, David A. Green DAG Consulting (480) 813-1725 www.dagconsulting.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fawaz Ashraff Sent: Tuesday, September 27, 2005 8:23 AM To: u2-users@listserver.u2ug.org Subject: [U2] Good Programming Practice Question. Hi All, We are planning to train some of our new programmers to use good programming practices when using U2 Basic. I can remember in Unidata days us having some tech support documents that talked about this. Example such as when is the best time to use CASE instead IF ELSE or not to use GOTO statments. I am sure some of you may have some input in this topic. If you have some documents, notes or thoughts on this, can you please share with us? When I get all the technical tips, I can compile this to a document and share with our new programmers as well as U2 listserver community. Thanks Mohamed --- 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/
Re: [U2] Good Programming Practice Question.........
A good example of interpeted vs non-interpeted code is that PROC can have the same label more than once. It will only reference the first one though. My 1 cent. - Original Message - From: Keith W. Roberts [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Cc: [EMAIL PROTECTED] Sent: Wednesday, September 28, 2005 4:22 PM Subject: RE: [U2] Good Programming Practice Question. Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon J Glorfield Sent: Wednesday, September 28, 2005 10:34 AM To: u2-users@listserver.u2ug.org Cc: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. I prefer alphanumeric labels for subroutines. The label should give some clue as to the function of the subroutine. The subroutines should be in frequency of use order with the most commonly used closer to the top of the program. Subroutines that are used once in a program (file opens, variable initialization, etc...) are located near the bottom. This method is suppose to improve the efficiency of the program and may not be valid anymore. Correct. There is absolutely no reason to order code by frequency of usage in a non-interpretive (ie, compiled) language. When the object is loaded into memory, relocatable jumps are resolved, so it's as efficient to get to the last line as the first. In the Sequoia version of Pick O/A it did matter. The run-time engine would start at the top of the program to search for a subroutine. Therefore a subroutine that was accessed over and over again would be found quicker each time if it was closer to the top. Some programmers even took this to an extreme by making the first line of a program read GOTO MAIN.LINE. The next line would be the label for the most commonly accessed subroutine. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 --- 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/
Re: [U2] Good Programming Practice Question.........
I've inherited a few apps whereby the data grew beyond any original ideas. Thus I *always* create my LAST variable outside of the loop. It gets exponential. I'm not worried about the extra variables in this sense. I have inherited such an incredible collection of crap over the years it's mind boggling. Having a consistent LAST=DCOUNT prior to a loop also lets me know what the last element is. I'm starting to use Accuterm GUI and its Gauge component wants to know the end. Perhaps not for everyone on this list as there are some pretty sharp people here, but sometimes I feel that I can improve almost any program I come across. It truly is an untamed world of compiled working source code out there (legacy) that at the very least, got us to where we are today. One simple question. Was it ever *required* to have the double quotes representing the unused DICT clause in an OPEN statement. I remember in 1978 being taught OPEN ,CUSTOMER TO F.CUSTOMER ELSE STOP 201,CUSTOMER and once accidentally forgetting the (,) and it didn't matter. To this day I've not run into a situation where it matters. Thanks in advance. - Original Message - From: Serguei Poliakov [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, September 29, 2005 5:27 AM Subject: Re: [U2] Good Programming Practice Question. Why do you need to create an extra variable (LAST)? It only make sense if the number of elements in ARRAY is really big. If you expect it to have 1 to 10 elements an extra variable only makes your code more difficult to maintain. On REMOVE I completely agree with you - it just makes it more difficult to understand the code without giving anything in return. - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 10:46 PM Subject: Re: [U2] Good Programming Practice Question. Another good suggestion: Use: LAST=DCOUNT(ARRAY,CHAR(253)) FOR I=1 TO LAST blah NEXT I instead of FOR I=1 TO DCOUNT(ARRAY,CHAR(253)) I know that REMOVE is pretty promoted here but most times I use a FOR/NEXT loop because I don't want to maintain a separate mv variable for using any other associated attributes. My 1 cent. - Original Message - From: Keith W. Roberts [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 5:14 PM Subject: RE: [U2] Good Programming Practice Question. I most heartily agree! Numbers in the labels don't elucidate; they merely increase the length. And I'm pretty sure I know that U comes somewhere after S. :) My $0.02 (on issues ancillary to the code itself) ... - make your BP files Type19 (DIR), so you can edit them outside of U2 using whatever cotton-pickin' editor you like - use source code control; absolutely anything is better than nothing, and there are good free ones for all platforms - agree on an indentation scheme and stick to it as a group, else get/create a beautifier which enforces the chosen standards before code checkin -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill_H Sent: Tuesday, September 27, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[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
RE: [U2] Good Programming Practice Question.........
This thread, while starting on noble grounds of 'good' programming practices, will eventually turn into a pissing contest of implied standards. I normally ignore you, but this one has me interested. Why must this otherwise educational topic be degraded into implication? -K --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
I think that there are a lot of good choices to choose from but there is no one *best* choice that we can all agree with. We've all come from separate environments that supported their own standards and we're coming to a focal point here debating the undebatable. I wonder if there could be a compilation of many programming methods that the new persons could pick and choose from. Perhaps on a topic by topic basis. Oddly enough, one programmer I've inherited, whose code it pretty all over the place, has actually inspired me to incorporate one of her methods into my bag of tricks. So, despite my general distain for her approach to things, I can gleen something useful for my future. My 1 cent. - Original Message - From: Fawaz Ashraff [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, September 29, 2005 4:33 PM Subject: RE: [U2] Good Programming Practice Question. Thanks a lot for all the input on this subject. Cheers Mohamed __ Yahoo! for Good Donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ --- 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/
RE: [U2] Good Programming Practice Question.........
[EMAIL PROTECTED] wrote: We also use xnn.meaningful.name type labels. One advantage is that our editor can recognise a label and putting the cursor on a line that includes a GOSUB and pressing one function key will move the cursor directly to the correct paragraph. One thing I've never agreed with (except in COBOL) is every internal subroutine should only have on exit point - why? Because it makes flow of control so much easier ... but mostly where I've seen it, it DOES make an exception for error handling. Maybe rephrase it - every internal subroutine should only exit from one point if it completes successfully. My two favourite rules were if a single logic-block won't fit on one screen, it's too big, and if a single section of code won't fit on one page of printout, it's too big. One of my colleagues tends to work to the mantra if it's only used once, it should be in-lined. Leads to huge programs where you enter at the top, fall out at the bottom, and get hopelessly lost in the detail. As the OO guy said, three lines is too big (I think that's an exageration :-) but DON'T start using trees to hide the wood! The ONLY time I would agree with inlining stuff like that is if your program doesn't have flow-control (ie, there are no loops (or backwards gotos in FORTRAN :-). So I tend to program with each section controlling a layer and calling subroutines (CALL or GOSUB, doesn't matter, usually GOSUB) to handle the tasks in the layer below. Which may themselves actually do something, or be a control layer. Actually, to sum up both my rules above, if there's a backward jump (LOOP, GOTO, FOR NEXT, whatever), and you can't see *both* the *start* *and* *end* at the same time on your preferred medium for making changes (screen for a small block of code, printout for the entire function, for me), then it's too big. (That's why it's *one* *page* of printout - I don't consider sheets of printout strewn over my desk as a preferred way of editing something! :-) Cheers, Wol --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
I may have missed someone else mentioning this, don't open files in an external subroutine that is called from within a loop. Yeah, yeah, I know you can set up a common, but isn't it cleaner to open the file in the main routine? Bruce M Neylon Health Care Management Group --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Two items I have thought of. 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. 2. Consider when to use a paragraph and when to use a program. Paragraphs (proc) certainly has their uses, but when the paragraph gets to using IF, Case, locate, etc seems time to use a program. For two reasons. One being while paragraphs (at least in SB+) can do a lot, getting it to do everything a program can do can be difficult. If you have an involved paragraph, sooner or later you'll be adding to it and find you can't easily add what you want to add, that it needs to be a program. Second reason being some of the commands are different syntax in a paragraph vs a program, why learn/memorize or have to look up two different syntaxes? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Also, I would always put the change date/time stamp on the same line, descending order, that way you can use/develop utilities to make mass changes (increase matrix size) and reliably insert a date/time stamp for the change. In my current job, we place the date/time stamp at the end and therefore cannot reliably automatically place a comment in the log since the position with differ with each program.. Vance Alspach J L Industrial Supply Marilyn Hilb [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/28/2005 10:47 AM Please respond to u2-users@listserver.u2ug.org To u2-users@listserver.u2ug.org cc Subject RE: [U2] Good Programming Practice Question. Two items I have thought of. 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. 2. Consider when to use a paragraph and when to use a program. Paragraphs (proc) certainly has their uses, but when the paragraph gets to using IF, Case, locate, etc seems time to use a program. For two reasons. One being while paragraphs (at least in SB+) can do a lot, getting it to do everything a program can do can be difficult. If you have an involved paragraph, sooner or later you'll be adding to it and find you can't easily add what you want to add, that it needs to be a program. Second reason being some of the commands are different syntax in a paragraph vs a program, why learn/memorize or have to look up two different syntaxes? --- 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/
RE: [U2] Good Programming Practice Question.........
Regarding the origin and revisions to software, DataFlo programmers pretty much have followed the policy where you try to flag all revisions in the software using the following convention: * Baseline changes use just a rev#, for example rev 01 * DataWorks use a rev# starting with a C, for example REV C1 * Custom Customer Programmers using a rev# starting with Z, for example REV Z1 Here is an excerpt illustrating this from a heavily modified program (from one of my customers): 0015: * D/W CUSTOM REVISIONS * 0016: ** Z5,04-20-04,KT-22,pault: Print SURCHARGE in footing instead of CUR. 0017: ** Z4,03-15-02,KORE,EWY: Display NET xxx DAYS 0018: ** Z3,01-03-02,KT-3024,CWV: Add copper credit to output 0019: ** Z2,04-24-00,KT2002,CWV: Remove REV 22, ALLOW ZERO DOLLAR INVOICE PRINT 0020: ** Z1,04-10-00,KT2001,CWV: Identify if report or proc 0021: ** 1C,03-05-99,39705,GEH: Added custom MFG PART number print 0022: R E V I S I O N S * 0023: ** 24,12-17-98,APP-079,EMW: Change dates to 4-digit year. 0024: ** 23,04-07-99,AR-1103,ABC: Print total with 2 decimal places. 0048: ** 00,09-11-95,AR-825,MLP: Rewrite at Rev 2. and the revisions are flagged like so: 0084: * REV 1C 0085: READV MFGPART.FLG FROM F.TABLE,PRT-CUST-PART,2 ELSE MFGPART.FLG=N 0086: * END REV 1C 0096:ZERO.LI= ; * REV 4 0158: * REV 7 Assign DTL 0159:DTL = 0160: * END REV 7 0938: * REV Z5 0939: *WORKVAR=WORKVAR:DISCPCTR#6: CUR 0940: WORKVAR=WORKVAR:DISCPCTR#6: SURCHARGE 0941: * END REV Z5 Note: * Revving your work this way usually makes it fairly easy to see what was added (REV 1C and REV 7) and what was changed (REV Z5). * Usually the baseline revisions are removed in a major software release - only in the baseline software. * When we 'upgrade' the software for a customer, for customized software components (i.e. Programs, Procs, Reports), we merge the baseline revisions into the customized software or visa versa (easier route). Using comparison tools the differences in the software component is pretty easy to find and usually pretty clear as to what to change. Have a Great Day! Paul Trebbien Kore Technologies, Senior Support Tech. Solutions that work. People who care. V 858.678.0030 F 858.300.2600 W koretech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Marilyn Hilb Sent: Wednesday, September 28, 2005 7:48 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Two items I have thought of. 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. 2. Consider when to use a paragraph and when to use a program. Paragraphs (proc) certainly has their uses, but when the paragraph gets to using IF, Case, locate, etc seems time to use a program. For two reasons. One being while paragraphs (at least in SB+) can do a lot, getting it to do everything a program can do can be difficult. If you have an involved paragraph, sooner or later you'll be adding to it and find you can't easily add what you want to add, that it needs to be a program. Second reason being some of the commands are different syntax in a paragraph vs a program, why learn/memorize or have to look up two different syntaxes? --- 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/
RE: [U2] Good Programming Practice Question.........
You know, I've seen a lot of people get really steamed that there was a RETURN in the middle of a well structured subroutine. Mostly because these people SCREWED UP when they put something at the bottom of the subroutine without checking, or worse TESTING the product before shoving it blindly into production. I see nothing wrong with a RETURN - especially in a validation subroutine. Now.an update subroutine is perhaps a bit different. If that needs to be broken up, I usually do it at the CALLING level, i.e.: BEGIN CASE CASE LEVEL1 GOSUB LEVEL1.UPDATES CASE LEVEL2 GOSUB LEVEL2.UPDATES CASE REPRINT GOSUB BUMP.REPRINT.COUNTER END CASE Here's something I thought about while looking at the possibility of not putting in a RETURN while at the same time keeping the code structured without a bunch of indented tabs: B00.PROCESS: BAD.HAPPENED = 1 LOOP READ REC1 FROM file1,id1 ELSE EXIT END READ REC2 FROM file2,id2 ELSE EXIT END IF some.condition THEN EXIT END BAD.HAPPENED = 0 EXIT REPEAT IF NOT(BAD.HAPPENED) THEN some more statements that actually do the work with REC1 REC2 END RETURN This does make it apparent that the subroutine is not being abandoned, while making a unique use of the LOOP/REPEAT/EXIT construct, in that it is not really a loop, but a method used for 'bouncing out'. It begins by assuming BAD.HAPPENED and will only negate this if it reaches the bottom of the decision stack. I've never used this before, and doubt that I will, but it was an intellectual exercise aimed at 'staying structured' with a minimum of IF/THEN's. Personally, I just use the RETURNno sense being 'analyst' about it.. ;) Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Womack, Adrian Sent: Tuesday, September 27, 2005 18:06 To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. We also use xnn.meaningful.name type labels. One advantage is that our editor can recognise a label and putting the cursor on a line that includes a GOSUB and pressing one function key will move the cursor directly to the correct paragraph. One thing I've never agreed with (except in COBOL) is every internal subroutine should only have on exit point - why? What is wrong with... B00.PROCESS: READ REC1 FROM file1,id1 ELSE RETURN READ REC2 FROM file2,id2 ELSE RETURN IF some.condition THEN RETURN some more statements that actually do the work with REC1 REC2 RETURN The early RETURNs are just getting out of the routine on abnormal conditions, the alternative would be to nest the code - but code nested more than a couple of tabs deep is *much* harder to read. AdrianW DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- 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/
RE: [U2] Good Programming Practice Question.........
I've got to disagree with this one. This is the job of your source code control system. I've seen applications which were commented in this manner over a number of years and they are almost unreadable due to the sheer volume of mod tags. -Original Message- [mailto:[EMAIL PROTECTED] Behalf Of Marilyn Hilb Sent: Wednesday, September 28, 2005 8:48 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Two items I have thought of. 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. [snip] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Paul: This brings up an interesting point. Why not keep information such as this in the database where, one might properly argue, it belongs? For years I did this but it dawned on me I couldn't slice and dice anything. As a result I simply created a single change file with about ten attributes. Then all my change descriptions, change dates, purpose of changes, who made changes, programs and processes changed, etc are placed in this one file. Now I can easily produce an Enhancement and Resolutions report with all changes. The code simply contains the original creation date, the data last changed, and the people responsible for each. The record key of the changes file is the date and time. Once this is accomplished I can create a wrapper around the editor and/or a trigger on the program file (depending on a slew of issues). In addition, I can link the changes to local O/S files that contain project documents, and other such helpful documents. Just a thought. :-) bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Trebbien Sent: Wednesday, September 28, 2005 8:35 AM To: 'u2-users@listserver.u2ug.org' Subject: RE: [U2] Good Programming Practice Question. Regarding the origin and revisions to software, DataFlo programmers pretty much have followed the policy where you try to flag all revisions in the software using the following convention: * Baseline changes use just a rev#, for example rev 01 * DataWorks use a rev# starting with a C, for example REV C1 * Custom Customer Programmers using a rev# starting with Z, for example REV Z1 Here is an excerpt illustrating this from a heavily modified program (from one of my customers): 0015: * D/W CUSTOM REVISIONS * 0016: ** Z5,04-20-04,KT-22,pault: Print SURCHARGE in footing instead of CUR. 0017: ** Z4,03-15-02,KORE,EWY: Display NET xxx DAYS 0018: ** Z3,01-03-02,KT-3024,CWV: Add copper credit to output 0019: ** Z2,04-24-00,KT2002,CWV: Remove REV 22, ALLOW ZERO DOLLAR INVOICE PRINT 0020: ** Z1,04-10-00,KT2001,CWV: Identify if report or proc 0021: ** 1C,03-05-99,39705,GEH: Added custom MFG PART number print 0022: R E V I S I O N S * 0023: ** 24,12-17-98,APP-079,EMW: Change dates to 4-digit year. 0024: ** 23,04-07-99,AR-1103,ABC: Print total with 2 decimal places. 0048: ** 00,09-11-95,AR-825,MLP: Rewrite at Rev 2. and the revisions are flagged like so: 0084: * REV 1C 0085: READV MFGPART.FLG FROM F.TABLE,PRT-CUST-PART,2 ELSE MFGPART.FLG=N 0086: * END REV 1C 0096:ZERO.LI= ; * REV 4 0158: * REV 7 Assign DTL 0159:DTL = 0160: * END REV 7 0938: * REV Z5 0939: *WORKVAR=WORKVAR:DISCPCTR#6: CUR 0940: WORKVAR=WORKVAR:DISCPCTR#6: SURCHARGE 0941: * END REV Z5 Note: * Revving your work this way usually makes it fairly easy to see what was added (REV 1C and REV 7) and what was changed (REV Z5). * Usually the baseline revisions are removed in a major software release - only in the baseline software. * When we 'upgrade' the software for a customer, for customized software components (i.e. Programs, Procs, Reports), we merge the baseline revisions into the customized software or visa versa (easier route). Using comparison tools the differences in the software component is pretty easy to find and usually pretty clear as to what to change. Have a Great Day! Paul Trebbien Kore Technologies, Senior Support Tech. Solutions that work. People who care. V 858.678.0030 F 858.300.2600 W koretech.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Marilyn Hilb Sent: Wednesday, September 28, 2005 7:48 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Two items I have thought of. 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. 2. Consider when to use a paragraph and when to use a program. Paragraphs (proc) certainly has their uses, but when the paragraph gets to using IF, Case, locate, etc seems time to use a program. For two reasons. One being while paragraphs (at least in SB+) can do a lot, getting it to do everything a program can do can be difficult. If you have an involved paragraph, sooner or later you'll be adding to it and find you can't easily add what you want to add, that it needs to be a program. Second reason being some
Re: [U2] Good Programming Practice Question.........
I'll agree with that. When I came on board at one site I found many programs that were commented in this manner with all lines commented out for changes. I remember one program in particular with over 1000 lines of code. After removing the commented out code and all of the references to ancient changes I came up with a program under 100 lines. - Original Message - From: Jeff Schasny [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Wednesday, September 28, 2005 10:55 AM Subject: RE: [U2] Good Programming Practice Question. I've got to disagree with this one. This is the job of your source code control system. I've seen applications which were commented in this manner over a number of years and they are almost unreadable due to the sheer volume of mod tags. -Original Message- [mailto:[EMAIL PROTECTED] Behalf Of Marilyn Hilb Sent: Wednesday, September 28, 2005 8:48 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Two items I have thought of. 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. [snip] --- 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/
RE: [U2] Good Programming Practice Question.........
One beauty of using a source control system like RCS or SCCS is that you do not need to maintain the mods in the source, the current running version of the source looks clean, but you can also view or print out the incremental differences. When I first introduced using RCS at one shop I got great resistance from programmers because they insisted on continuing to flag a project's mods as described by others in this thread. A year later they were so disgusted by this practice, that they demanded an internal project to go through and rip them out because RCS did such a nice job of it all by itself. cds 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
I prefer alphanumeric labels for subroutines. The label should give some clue as to the function of the subroutine. The subroutines should be in frequency of use order with the most commonly used closer to the top of the program. Subroutines that are used once in a program (file opens, variable initialization, etc...) are located near the bottom. This method is suppose to improve the efficiency of the program and may not be valid anymore. In the Sequoia version of Pick O/A it did matter. The run-time engine would start at the top of the program to search for a subroutine. Therefore a subroutine that was accessed over and over again would be found quicker each time if it was closer to the top. Some programmers even took this to an extreme by making the first line of a program read GOTO MAIN.LINE. The next line would be the label for the most commonly accessed subroutine. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 09/27/2005 04:35:12 PM: Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill [SNIP] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Strange, while we are discussing this Gus has already set up a web seminar on the subject: http://www.intl-spectrum.com/learn%20more%20page.3A.htm --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon J Glorfield Sent: Wednesday, September 28, 2005 10:34 AM To: u2-users@listserver.u2ug.org Cc: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. I prefer alphanumeric labels for subroutines. The label should give some clue as to the function of the subroutine. The subroutines should be in frequency of use order with the most commonly used closer to the top of the program. Subroutines that are used once in a program (file opens, variable initialization, etc...) are located near the bottom. This method is suppose to improve the efficiency of the program and may not be valid anymore. Correct. There is absolutely no reason to order code by frequency of usage in a non-interpretive (ie, compiled) language. When the object is loaded into memory, relocatable jumps are resolved, so it's as efficient to get to the last line as the first. In the Sequoia version of Pick O/A it did matter. The run-time engine would start at the top of the program to search for a subroutine. Therefore a subroutine that was accessed over and over again would be found quicker each time if it was closer to the top. Some programmers even took this to an extreme by making the first line of a program read GOTO MAIN.LINE. The next line would be the label for the most commonly accessed subroutine. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
But from what I understand Unidata does not produce compiled object code. It creates compiled P-Code, which is then interpreted at run time. True? False? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Keith W. Roberts Sent: Wednesday, September 28, 2005 13:22 To: u2-users@listserver.u2ug.org Cc: [EMAIL PROTECTED] Subject: RE: [U2] Good Programming Practice Question. Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon J Glorfield Sent: Wednesday, September 28, 2005 10:34 AM To: u2-users@listserver.u2ug.org Cc: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. I prefer alphanumeric labels for subroutines. The label should give some clue as to the function of the subroutine. The subroutines should be in frequency of use order with the most commonly used closer to the top of the program. Subroutines that are used once in a program (file opens, variable initialization, etc...) are located near the bottom. This method is suppose to improve the efficiency of the program and may not be valid anymore. Correct. There is absolutely no reason to order code by frequency of usage in a non-interpretive (ie, compiled) language. When the object is loaded into memory, relocatable jumps are resolved, so it's as efficient to get to the last line as the first. In the Sequoia version of Pick O/A it did matter. The run-time engine would start at the top of the program to search for a subroutine. Therefore a subroutine that was accessed over and over again would be found quicker each time if it was closer to the top. Some programmers even took this to an extreme by making the first line of a program read GOTO MAIN.LINE. The next line would be the label for the most commonly accessed subroutine. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 --- 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/
RE: [U2] Good Programming Practice Question.........
Goo'day, At 09:55 28/09/05 -0600, you wrote: I've got to disagree with this one. This is the job of your source code control system. I've seen applications which were commented in this manner over a number of years and they are almost unreadable due to the sheer volume of mod tags. We take the approach to keep the stamp and story at the top, but remove the tags after a while. -Original Message- [mailto:[EMAIL PROTECTED] Behalf Of Marilyn Hilb Sent: Wednesday, September 28, 2005 8:48 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Two items I have thought of. 1. In addition to putting a modification tag at the top of the code with who/date/what, we also will assign a job number to the mod in addition to a No for the mod. Such as mod 01. Then throughout the code where the changes are made we put a tag such as *01 start and *01 end or, just a single tag at the end of the line if only one or two lines being changed. This makes the changes very easy to search for and spot should there be problems in the new code. [snip] --- 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.8/113 - Release Date: 27/09/05 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.8/113 - Release Date: 27/09/05 Regards, Bruce Nichol Talon Computer Services ALBURYNSW 2640 Australia http://www.taloncs.com.au Tel: +61 (0)411149636 Fax: +61 (0)260232119 If it ain't broke, fix it till it is! -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.8/113 - Release Date: 27/09/05 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Good Programming Practice Question.........
Hi All, We are planning to train some of our new programmers to use good programming practices when using U2 Basic. I can remember in Unidata days us having some tech support documents that talked about this. Example such as when is the best time to use CASE instead IF ELSE or not to use GOTO statments. I am sure some of you may have some input in this topic. If you have some documents, notes or thoughts on this, can you please share with us? When I get all the technical tips, I can compile this to a document and share with our new programmers as well as U2 listserver community. Thanks Mohamed __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
I've been teaching UniBasic for over 10 years and here are some of the methods I teach: * Subroutines should only have one job. * Subroutines should be short. (less than 10 lines) * Subroutines should have one entrance and one exit. * Use meaningful variable names and subroutine names. * Be consistent in your naming conventions. * Don't hard code Numbers, Strings, or Attributes. * Use CASE over IF...THEN when there are more than two options. * Use LOOP...WHILE/UNTIL...REPEAT over FOR...NEXT with IF Conditions. * Use REMOVE to traverse a dynamic array. * Use a Simple Variable on Conditional Statements. * Use UniData Internal Variables whenever possible; i.e. @AM, @VM, @DATE. Thank you, David A. Green DAG Consulting (480) 813-1725 www.dagconsulting.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fawaz Ashraff Sent: Tuesday, September 27, 2005 8:23 AM To: u2-users@listserver.u2ug.org Subject: [U2] Good Programming Practice Question. Hi All, We are planning to train some of our new programmers to use good programming practices when using U2 Basic. I can remember in Unidata days us having some tech support documents that talked about this. Example such as when is the best time to use CASE instead IF ELSE or not to use GOTO statments. I am sure some of you may have some input in this topic. If you have some documents, notes or thoughts on this, can you please share with us? When I get all the technical tips, I can compile this to a document and share with our new programmers as well as U2 listserver community. Thanks Mohamed __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com --- 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/
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: I've been teaching UniBasic for over 10 years and here are some of the methods I teach: * Subroutines should only have one job. * Subroutines should be short. (less than 10 lines) * Subroutines should have one entrance and one exit. * Use meaningful variable names and subroutine names. * Be consistent in your naming conventions. * Don't hard code Numbers, Strings, or Attributes. * Use CASE over IF...THEN when there are more than two options. * Use LOOP...WHILE/UNTIL...REPEAT over FOR...NEXT with IF Conditions. * Use REMOVE to traverse a dynamic array. * Use a Simple Variable on Conditional Statements. * Use UniData Internal Variables whenever possible; i.e. @AM, @VM, @DATE. Thank you, David A. Green DAG Consulting (480) 813-1725 www.dagconsulting.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fawaz Ashraff Sent: Tuesday, September 27, 2005 8:23 AM To: u2-users@listserver.u2ug.org Subject: [U2] Good Programming Practice Question. Hi All, We are planning to train some of our new programmers to use good programming practices when using U2 Basic. I can remember in Unidata days us having some tech support documents that talked about this. Example such as when is the best time to use CASE instead IF ELSE or not to use GOTO statments. I am sure some of you may have some input in this topic. If you have some documents, notes or thoughts on this, can you please share with us? When I get all the technical tips, I can compile this to a document and share with our new programmers as well as U2 listserver community. Thanks Mohamed --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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/
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/
RE: [U2] Good Programming Practice Question.........
Yes good one. The more readable your code the easier to DEBUG and to reuse. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dianne Ackerman Sent: Tuesday, September 27, 2005 11:57 AM 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: I've been teaching UniBasic for over 10 years and here are some of the methods I teach: * Subroutines should only have one job. * Subroutines should be short. (less than 10 lines) * Subroutines should have one entrance and one exit. * Use meaningful variable names and subroutine names. * Be consistent in your naming conventions. * Don't hard code Numbers, Strings, or Attributes. * Use CASE over IF...THEN when there are more than two options. * Use LOOP...WHILE/UNTIL...REPEAT over FOR...NEXT with IF Conditions. * Use REMOVE to traverse a dynamic array. * Use a Simple Variable on Conditional Statements. * Use UniData Internal Variables whenever possible; i.e. @AM, @VM, @DATE. Thank you, David A. Green DAG Consulting (480) 813-1725 www.dagconsulting.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fawaz Ashraff Sent: Tuesday, September 27, 2005 8:23 AM To: u2-users@listserver.u2ug.org Subject: [U2] Good Programming Practice Question. Hi All, We are planning to train some of our new programmers to use good programming practices when using U2 Basic. I can remember in Unidata days us having some tech support documents that talked about this. Example such as when is the best time to use CASE instead IF ELSE or not to use GOTO statments. I am sure some of you may have some input in this topic. If you have some documents, notes or thoughts on this, can you please share with us? When I get all the technical tips, I can compile this to a document and share with our new programmers as well as U2 listserver community. Thanks Mohamed --- 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/
Re: [U2] Good Programming Practice Question.........
On 9/27/05, Dianne Ackerman [EMAIL PROTECTED] wrote: I like these and would add another one - Add comments to tricky-looking code! -Dianne And DON'T add comments to the mundane routine stuff!! --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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/
RE: [U2] Good Programming Practice Question.........
I think we have a good start and thanks for all the input. Can you guys also include technical information as well. I am sure you would have encounted some way of programming gives faster results than the others. Let's say as an example, if you are opening a program all the time, just to make it a COMMON variable.. --- Allen E. Elwood [EMAIL PROTECTED] wrote: 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/ __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
In addition to using subroutines, when developing with UniVerse and SB+ I often have one application handle many, if not all of the screen and report processing. This helps keep things in one place. For this I use the ON GOSUB construct of the BASIC language. It's worth noting depending on its application or relevance. I've been teaching UniBasic for over 10 years and here are some of the methods I teach: * Subroutines should only have one job. * Subroutines should be short. (less than 10 lines) * Subroutines should have one entrance and one exit. * Use meaningful variable names and subroutine names. * Be consistent in your naming conventions. * Don't hard code Numbers, Strings, or Attributes. * Use CASE over IF...THEN when there are more than two options. * Use LOOP...WHILE/UNTIL...REPEAT over FOR...NEXT with IF Conditions. * Use REMOVE to traverse a dynamic array. * Use a Simple Variable on Conditional Statements. * Use UniData Internal Variables whenever possible; i.e. @AM, @VM, @DATE. Thank you, David A. Green DAG Consulting (480) 813-1725 www.dagconsulting.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fawaz Ashraff Sent: Tuesday, September 27, 2005 8:23 AM To: u2-users@listserver.u2ug.org Subject: [U2] Good Programming Practice Question. Hi All, We are planning to train some of our new programmers to use good programming practices when using U2 Basic. I can remember in Unidata days us having some tech support documents that talked about this. Example such as when is the best time to use CASE instead IF ELSE or not to use GOTO statments. I am sure some of you may have some input in this topic. If you have some documents, notes or thoughts on this, can you please share with us? When I get all the technical tips, I can compile this to a document and share with our new programmers as well as U2 listserver community. Thanks Mohamed --- 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/
RE: [U2] Good Programming Practice Question.........
AhI always put my subroutines in the same order as they are in the main calling section. And using Accuterm, if you highlight the SELECT.FILE portion of the GOSUB SELECT.FILE, then hit CTRL-F it puts SELECT.FILE in there for you and Bingo, you're there. I get tired of the redundancy of using GOSUB 100 ; * Display Page instead of GOSUB DISPLAY.PAGE And and andI've seen PLENTY of programs where 2200 was below 4000 - sad - but true!! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kevin King Sent: Tuesday, September 27, 2005 13:04 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/
Re: [U2] Good Programming Practice Question.........
Try not to use dim arrays to hold file variables. difficult to diag. Keep label and variable names to 14 chars and under for universe's xrefer Avoid ever 'falling' into a label Never branch around stuff Sometimes its nice to comment CASE statements CASE LEN(ID) LE 5 ;* its a phone number .. On 9/27/05, Fawaz Ashraff [EMAIL PROTECTED] wrote: Hi All, We are planning to train some of our new programmers to use good programming practices when using U2 Basic. I can remember in Unidata days us having some tech support documents that talked about this. Example such as when is the best time to use CASE instead IF ELSE or not to use GOTO statments. I am sure some of you may have some input in this topic. If you have some documents, notes or thoughts on this, can you please share with us? When I get all the technical tips, I can compile this to a document and share with our new programmers as well as U2 listserver community. Thanks Mohamed __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com --- 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/
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/
RE: [U2] Good Programming Practice Question.........
But I take the middle road with labels like: A001.mainline: code RETURN ;* from A001.mainline A010.open.and.init B100.select.file B200.pre-process.validity.checks C500.print.invoices C700.update.files Z900.error that I order by prefix. I get ordering, description, and grouping. I also use white space to separate paragraphs. Of course for many my use of mixed case is a matter of dispute. Karjala [EMAIL PROTECTED] 09/27/2005 4:03:38 PM 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/
RE: [U2] Good Programming Practice Question.........
Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[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/
Re: [U2] Good Programming Practice Question.........
We usually wrap this in a LOOP REPEAT and case statements using an action code that changes for the completion of each routine. ACTION = 'INIT' LOOP UNTIL ACTION = 'ABORT' OR ACTION = 'EOJ' DO BEGIN CASE CASE ACTION = 'INIT' GOSUB OPEN.AND.INIT CASE ACTION = 'SELECT' GOSUB SELECT.FILE CASE ACTION = 'PROCESS' GOSUB PRE-PROCESS.VALIDITY.CHECKS CASE ACTION = 'PRINT' GOSUB PRINT.INVOICES CASE ACTION = 'UPDATE' GOSUB UPDATE.FILES REPEAT STOP - Original Message - From: Allen E. Elwood [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 2:40 PM 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
Kevin, I disagree, for a simple reason: I use alpha labels that make sense and then place them in the code in alphabetical order. Problem solved grin. Just a few off the top of my head (it's late here): 1. If using UniVerse, use mixed case to encourage readability when scanning through a program with upper case reserved for constants, common, file and select variables so they stand out as different, as in: Fin = @False Loop ReadNext Id From SLIST Else Fin = @True Until Fin Do Read OrderRec From ORDERS, Id Then GoSub ProcessRecord End Repeat 2. A GoSub should perform a single action. Jumping into a second label inside a GoSub just sucks. Return To should be banned. 3. Have a single exit point from a program or subroutine. 4. Separate out the business logic from the screen processing (if any): that way if you want to reengineer the application or reuse the rules in another context it is so much easier. 5. Hold file variables in named common. 6. Name record variables after the file from which they originate. 7. Equate all field names (preferably automatically) in include files. I use the format FILENAME.FIELDNAME to disambiguate e.g. EQU CUSTOMER.SURNAME TO 1 So I can reference: CustomerRecCUSTOMER.SURNAME Above all, be consistent. There are many good practices out there, most of them are common sense but they only work if applied consistently. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: 27 September 2005 21:04 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/
RE: [U2] Good Programming Practice Question.........
alphabetize the labels? You mean sort?? :-) -K -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill_H Sent: Tuesday, September 27, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
I personally would rather use alpha-numeric labels because of the many programs I have come across that tend to not have comments. You can always use a locate to find the subroutine especially if you use correct labeling with a colon at the end. END.OF.PROGRAM: - Original Message - From: Kevin King [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 3:03 PM 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/
RE: [U2] Good Programming Practice Question.........
I prefer alphanumeric labels for subroutines. The label should give some clue as to the function of the subroutine. The subroutines should be in frequency of use order with the most commonly used closer to the top of the program. Subroutines that are used once in a program (file opens, variable initialization, etc...) are located near the bottom. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 09/27/2005 04:35:12 PM: Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill [SNIP] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
What about lock management? 1. Lock all records that are going to be updated ... even if the update is really a delete 2. Release your locks promptly (either with a RELEASE, WRITE or DELETE statement) - don't let the program termination be the time when record locks are released 3. Use the LOCKED clause so the application can decide what to do when a record is locked rather than the database P. Michael Logue U2 Technical Support Engineer U2 Products Service Planner IBM Certified Solutions Expert in U2 Application Development IBM Certified U2 UniData Administration IBM Information Management Division, Software Group Phone: 303-773-7846 Tie Line: 656-7846 Email: [EMAIL PROTECTED] www.ibm.com/software/data/u2/support Open, Query, Update, Search - Online! --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
I most heartily agree! Numbers in the labels don't elucidate; they merely increase the length. And I'm pretty sure I know that U comes somewhere after S. :) My $0.02 (on issues ancillary to the code itself) ... - make your BP files Type19 (DIR), so you can edit them outside of U2 using whatever cotton-pickin' editor you like - use source code control; absolutely anything is better than nothing, and there are good free ones for all platforms - agree on an indentation scheme and stick to it as a group, else get/create a beautifier which enforces the chosen standards before code checkin -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill_H Sent: Tuesday, September 27, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[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=* --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
I'll toss in 2 cents on 'standards'. If maintaining an existing environment, should you add a new standard (yours) or should you adhere to the primary one already there. For example, I use OPEN CUST TO F.CUST ELSE STOP whereas one app has OPEN CUST TO CUST.FILE ELSE STOP I agree with many of the suggestions when having the luxury of designing an application from scratch. However, many times one inherits previous standards and sometimes they should prevail. Two observations: 1. MV programming is a box of crayons and if it compiles and 1+1 does equal 2, then it works. 2. The good thing about standards is that there are so many to choose from. P.S. Actually I use a sub CALL OPENER(CUST, F.CUST) but the point was the style of the file handle. - Original Message - From: Keith W. Roberts [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 5:14 PM Subject: RE: [U2] Good Programming Practice Question. I most heartily agree! Numbers in the labels don't elucidate; they merely increase the length. And I'm pretty sure I know that U comes somewhere after S. :) My $0.02 (on issues ancillary to the code itself) ... - make your BP files Type19 (DIR), so you can edit them outside of U2 using whatever cotton-pickin' editor you like - use source code control; absolutely anything is better than nothing, and there are good free ones for all platforms - agree on an indentation scheme and stick to it as a group, else get/create a beautifier which enforces the chosen standards before code checkin -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill_H Sent: Tuesday, September 27, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[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=* --- 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/
Re: [U2] Good Programming Practice Question.........
Another good suggestion: Use: LAST=DCOUNT(ARRAY,CHAR(253)) FOR I=1 TO LAST blah NEXT I instead of FOR I=1 TO DCOUNT(ARRAY,CHAR(253)) I know that REMOVE is pretty promoted here but most times I use a FOR/NEXT loop because I don't want to maintain a separate mv variable for using any other associated attributes. My 1 cent. - Original Message - From: Keith W. Roberts [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 5:14 PM Subject: RE: [U2] Good Programming Practice Question. I most heartily agree! Numbers in the labels don't elucidate; they merely increase the length. And I'm pretty sure I know that U comes somewhere after S. :) My $0.02 (on issues ancillary to the code itself) ... - make your BP files Type19 (DIR), so you can edit them outside of U2 using whatever cotton-pickin' editor you like - use source code control; absolutely anything is better than nothing, and there are good free ones for all platforms - agree on an indentation scheme and stick to it as a group, else get/create a beautifier which enforces the chosen standards before code checkin -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill_H Sent: Tuesday, September 27, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[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=* --- 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/
Re: [U2] Good Programming Practice Question.........
Another suggestion: Since the RETURN statement actually has 2 meanings, I add a comment at the end of the RETURN that concludes a called subroutine, especially if there are internal subroutines within it. RETURN ;* TO CALLING PROGRAM I'm glad we don't have POP and wince when I see RETURN TO. Mark Johnson P.S. I would also love to see an analyzer program that identifies whether OPENed files READ, WRITE, CLEAR and/or DELETE. It could be a comment at the end of the OPEN statement. Often times I FIND a BP file for CUSTOMER and WRITE but they're not necessarily attached. OPEN CUSTOMER TO F.CUSTOMER ELSE STOP ;* RWCD - Original Message - From: Keith W. Roberts [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 5:14 PM Subject: RE: [U2] Good Programming Practice Question. I most heartily agree! Numbers in the labels don't elucidate; they merely increase the length. And I'm pretty sure I know that U comes somewhere after S. :) My $0.02 (on issues ancillary to the code itself) ... - make your BP files Type19 (DIR), so you can edit them outside of U2 using whatever cotton-pickin' editor you like - use source code control; absolutely anything is better than nothing, and there are good free ones for all platforms - agree on an indentation scheme and stick to it as a group, else get/create a beautifier which enforces the chosen standards before code checkin -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill_H Sent: Tuesday, September 27, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[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=* --- 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/
RE: [U2] Good Programming Practice Question.........
Kevin: Yes. For example: GOSUB INIT.GLOBAL GOSUB INIT.LOCAL GOSUB OPEN.FILES GOSUB GET.CONFIG . LOOP READNEXT ID ELSE EXIT GOSUB READ.DATA GOSUB UPDATE.DATA GOSUB WRITE.DATA REPEAT GOTO END.OF.PROGRAM . *** GET.CONFIG: *** . RETURN * *** INIT.GLOBAL: *** . RETURN * *** INIT.LOCAL: *** . RETURN * *** OPEN.FILES: *** . RETURN * *** READ.DATA: *** . RETURN * *** UPDATE.DATA: *** . RETURN * *** WRITE.DATA: *** . RETURN * *** END.OF.PROGRAM: *** RETURN (If Subroutine) END Hope I didn't create confusion. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: Tuesday, September 27, 2005 1:51 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. alphabetize the labels? You mean sort?? :-) -K -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill_H Sent: Tuesday, September 27, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill --- 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/
RE: [U2] Good Programming Practice Question.........
I recommend that everyone buy/borrow a copy of Code Complete by Steve McConnell. It has several sections dedicated to good coding practices. Readability is key, since we read programs hundreds of times more than we write them. The book offers lots of strategies to improve readability, like different ways to reduce nested IF's, simplifying LOOP's and CASE statements, etc. and offers coding horrors to avoid. rex --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Mark Johnson P.S. I would also love to see an analyzer program that identifies whether OPENed files READ, WRITE, CLEAR and/or DELETE. It could be a comment at the end of the OPEN statement. Often times I FIND a BP file for CUSTOMER and WRITE but they're not necessarily attached. I like having a single subroutine that performs all opens especially one for all writes (including DELETES). This gives you better control, including the ability to track all writes/opens if or when you need to, and to enforce any rules you wish to apply. Our greatest duty in this life is to help others. And please, if you can't help them, could you at least not hurt them? - H.H. the Dalai Lama When buying selling are controlled by legislation, the first thing to be bought sold are the legislators - P.J. O'Rourke Dan Fitzgerald --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
Ugh! My personal preference. The only reason I use mixed case is for comments. With Universe differentiating between case (OrderRec is not orderrec or ORDERREC) you have to remember the way you mixed the case. Also, it makes it easier to recognize the comment lines in the code. When modifying code if you can't re-write the program always use the same standard used in the existing program otherwise it gets confusing to the next programmer that picks up the program. - Original Message - From: Brian Leach [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 3:48 PM Subject: RE: [U2] Good Programming Practice Question. Kevin, I disagree, for a simple reason: I use alpha labels that make sense and then place them in the code in alphabetical order. Problem solved grin. Just a few off the top of my head (it's late here): 1. If using UniVerse, use mixed case to encourage readability when scanning through a program with upper case reserved for constants, common, file and select variables so they stand out as different, as in: Fin = @False Loop ReadNext Id From SLIST Else Fin = @True Until Fin Do Read OrderRec From ORDERS, Id Then GoSub ProcessRecord End Repeat 2. A GoSub should perform a single action. Jumping into a second label inside a GoSub just sucks. Return To should be banned. 3. Have a single exit point from a program or subroutine. 4. Separate out the business logic from the screen processing (if any): that way if you want to reengineer the application or reuse the rules in another context it is so much easier. 5. Hold file variables in named common. 6. Name record variables after the file from which they originate. 7. Equate all field names (preferably automatically) in include files. I use the format FILENAME.FIELDNAME to disambiguate e.g. EQU CUSTOMER.SURNAME TO 1 So I can reference: CustomerRecCUSTOMER.SURNAME Above all, be consistent. There are many good practices out there, most of them are common sense but they only work if applied consistently. Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: 27 September 2005 21:04 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
RE: [U2] Good Programming Practice Question.........
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
Re[2]: [U2] Good Programming Practice Question.........
Brian, though mixed case IS easier for reading it seems simpler to just use camelBack .. Tuesday, September 27, 2005, 1:48:46 PM, you wrote: BL Kevin, BL I disagree, for a simple reason: BL I use alpha labels that make sense and then place them in the code in BL alphabetical order. BL Problem solved grin. BL Just a few off the top of my head (it's late here): BL 1. If using UniVerse, use mixed case to encourage readability when scanning BL through a program with upper case reserved for constants, common, file and BL select variables so they stand out as different, as in: BL Fin = @False BL Loop BL ReadNext Id From SLIST Else Fin = @True BL Until Fin Do BL Read OrderRec From ORDERS, Id Then BL GoSub ProcessRecord BL End BL Repeat BL 2. A GoSub should perform a single action. Jumping into a second label BL inside a GoSub just sucks. BLReturn To should be banned. BL 3. Have a single exit point from a program or subroutine. BL 4. Separate out the business logic from the screen processing (if any): BLthat way if you want to reengineer the application or reuse the rules in BL another context it is so much easier. BL 5. Hold file variables in named common. BL 6. Name record variables after the file from which they originate. BL 7. Equate all field names (preferably automatically) in include files. BLI use the format FILENAME.FIELDNAME to disambiguate e.g. BLEQU CUSTOMER.SURNAME TO 1 BLSo I can reference: BL CustomerRecCUSTOMER.SURNAME BL BL Above all, be consistent. There are many good practices out there, most of BL them are common sense but they only work if applied consistently. BL Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King Sent: 27 September 2005 21:04 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
RE: [U2] Good Programming Practice Question.........
Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach Sent: Tuesday, September 27, 2005 1:49 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin, I disagree, for a simple reason: I use alpha labels that make sense and then place them in the code in alphabetical order. Problem solved grin. Just a few off the top of my head (it's late here): 1. If using UniVerse, use mixed case to encourage readability when scanning through a program with upper case reserved for constants, common, file and select variables so they stand out as different, as in: Fin = @False Loop ReadNext Id From SLIST Else Fin = @True Until Fin Do Read OrderRec From ORDERS, Id Then GoSub ProcessRecord End Repeat This is style, rather than good coding practice. To each their own. 2. A GoSub should perform a single action. Jumping into a second label inside a GoSub just sucks. Return To should be banned. Nothing wrong with nested routines, but in that case RETURN TO is anathema. This is one of the few really bad design flaws of BASIC, that they chose not to use a separate keyword for returning from a GOSUB, or at least use a separate return stack. For example, if they'd paired: CALL ... RETURN and GOSUB ... RTN, and CALL pushed to Stack1 and GOSUB to Stack2, then implementing RETURN *anywhere* in the program would be as simple as CLEAR Stack2; POP Stack1, and doing a RETURN TO from a secondary or tertiary GOSUB wouldn't be a problem. [snip] Above all, be consistent. There are many good practices out there, most of them are common sense but they only work if applied consistently. Amen to that. -Keith --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re[2]: [U2] Good Programming Practice Question.........
Jerry, Tuesday, September 27, 2005, 3:09:02 PM, you wrote: JB Ugh! My personal preference. The only reason I use mixed case is for JB comments. With Universe differentiating between case (OrderRec is not JB orderrec or ORDERREC) you have to remember the way you mixed the case. you should be able to remember what vars you used .. it becomes habit .. just like THIS BECOMES A HABIT. JB Also, it makes it easier to recognize the comment lines in the JB code. a good editor with syntax highlighting makes recongizing comments even easier JB When modifying code if you can't re-write the program always use the same JB standard used in the existing program otherwise it gets confusing to the JB next programmer that picks up the program. true .. when you are making changes .. but new stuff can start a new trend. we used to use punch cards .. but I moved on .. and if I can move on then anybody can G -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
RETURN with a comment..that is an excellent suggestion. Nancy - Original Message - From: Mark Johnson [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 2:51 PM Subject: Re: [U2] Good Programming Practice Question. Another suggestion: Since the RETURN statement actually has 2 meanings, I add a comment at the end of the RETURN that concludes a called subroutine, especially if there are internal subroutines within it. RETURN ;* TO CALLING PROGRAM I'm glad we don't have POP and wince when I see RETURN TO. Mark Johnson P.S. I would also love to see an analyzer program that identifies whether OPENed files READ, WRITE, CLEAR and/or DELETE. It could be a comment at the end of the OPEN statement. Often times I FIND a BP file for CUSTOMER and WRITE but they're not necessarily attached. OPEN CUSTOMER TO F.CUSTOMER ELSE STOP ;* RWCD - Original Message - From: Keith W. Roberts [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, September 27, 2005 5:14 PM Subject: RE: [U2] Good Programming Practice Question. I most heartily agree! Numbers in the labels don't elucidate; they merely increase the length. And I'm pretty sure I know that U comes somewhere after S. :) My $0.02 (on issues ancillary to the code itself) ... - make your BP files Type19 (DIR), so you can edit them outside of U2 using whatever cotton-pickin' editor you like - use source code control; absolutely anything is better than nothing, and there are good free ones for all platforms - agree on an indentation scheme and stick to it as a group, else get/create a beautifier which enforces the chosen standards before code checkin -Keith Original Message From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill_H Sent: Tuesday, September 27, 2005 1:35 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[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=* --- 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/
[OT]RE: Re[2]: [U2] Good Programming Practice Question.........
true .. when you are making changes .. but new stuff can start a new trend. we used to use punch cards .. but I moved on .. and if I can move on then anybody can G You don't use punch cards? How do you make your programs run? Our greatest duty in this life is to help others. And please, if you can't help them, could you at least not hurt them? - H.H. the Dalai Lama When buying selling are controlled by legislation, the first thing to be bought sold are the legislators - P.J. O'Rourke Dan Fitzgerald --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [ ] - RE: [U2] Good Programming Practice Question......... - Found word(s) list error in the Text body
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
RE: [U2] Good Programming Practice Question.........
I haven't heard it said (much) lately so if I missed it, forgive me. STANDARDS ARE ESSENTIAL I have standards for structure, header/commenting, everything including variable names. Everything is done with purpose and according to standard, which makes it very easy to recognize code and its meaning months - even years - after it's been written. Today in particular I'm into code that I wrote in 1993 and it's as fresh as if it were written today. -K -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gordon J Glorfield Sent: Tuesday, September 27, 2005 2:17 PM To: u2-users@listserver.u2ug.org Cc: [EMAIL PROTECTED]; u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. I prefer alphanumeric labels for subroutines. The label should give some clue as to the function of the subroutine. The subroutines should be in frequency of use order with the most commonly used closer to the top of the program. Subroutines that are used once in a program (file opens, variable initialization, etc...) are located near the bottom. Gordon J. Glorfield Sr. Applications Developer MAMSI (A UnitedHealth Company) 301-360-8839 [EMAIL PROTECTED] wrote on 09/27/2005 04:35:12 PM: Kevin: Not if you alphabetize the labels; then it works just like numeric. :-) Bill [SNIP] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --- 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/
Re: [OT]RE: Re[2]: [U2] Good Programming Practice Question.........
Dan, Tuesday, September 27, 2005, 3:39:21 PM, you wrote: true .. when you are making changes .. but new stuff can start a new trend. we used to use punch cards .. but I moved on .. and if I can move on then anybody can G DF You don't use punch cards? How do you make your programs run? i send them to my guru buddies and let them make them run .. -- DSig ` David Tod Sigafoos ( O O ) ___oOOo__( )__oOOo___ ...our behavior matters more than the beliefs that we profess. Elizabeth Deutsch Earle --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Good Programming Practice Question.........
RETURN with a comment..that is an excellent suggestion. I'd argue that any END statement that's more than a handful (8-10) lines from the opening IF (or whatever) statement should have a comment. Here's an example (that's not long enough to satisfy my 'handful' argument above): IF XOOS.ALL.COURSES='Y' THEN some lines of code END ELSE ;* IF XOOS.ALL.COURSES='Y' THEN some lines of code END ;* IF XOOS.ALL.COURSES='Y' THEN Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 ...our behavior matters more than the beliefs that we profess. Elizabeth Deutsch Earle --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
We also use xnn.meaningful.name type labels. One advantage is that our editor can recognise a label and putting the cursor on a line that includes a GOSUB and pressing one function key will move the cursor directly to the correct paragraph. One thing I've never agreed with (except in COBOL) is every internal subroutine should only have on exit point - why? What is wrong with... B00.PROCESS: READ REC1 FROM file1,id1 ELSE RETURN READ REC2 FROM file2,id2 ELSE RETURN IF some.condition THEN RETURN some more statements that actually do the work with REC1 REC2 RETURN The early RETURNs are just getting out of the routine on abnormal conditions, the alternative would be to nest the code - but code nested more than a couple of tabs deep is *much* harder to read. AdrianW DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Good Programming Practice Question.........
This is where the FIND command becomes handy From: [EMAIL PROTECTED] on behalf of Kevin King Sent: Tue 9/27/2005 4:03 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/
RE: [U2] Good Programming Practice Question.........
Allen: I know we've seen the same crappy code LOL From: [EMAIL PROTECTED] on behalf of Allen E. Elwood Sent: Tue 9/27/2005 4:27 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Good Programming Practice Question. AhI always put my subroutines in the same order as they are in the main calling section. And using Accuterm, if you highlight the SELECT.FILE portion of the GOSUB SELECT.FILE, then hit CTRL-F it puts SELECT.FILE in there for you and Bingo, you're there. I get tired of the redundancy of using GOSUB 100 ; * Display Page instead of GOSUB DISPLAY.PAGE And and andI've seen PLENTY of programs where 2200 was below 4000 - sad - but true!! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Kevin King Sent: Tuesday, September 27, 2005 13:04 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/
RE: [U2] Good Programming Practice Question.........
I hope you're joking - talk about making code unreadable, comments that look like code are (IMO) a very BAD idea. The indentation level makes it perfectly clear what goes with what, and if it doesn't then change the structure of the code. IMO IF XOOS.ALL.COURSES='Y' THEN some lines of code END ELSE ;* IF XOOS.ALL.COURSES='Y' THEN some lines of code END ;* IF XOOS.ALL.COURSES='Y' THEN is much less clear than my preferred way of formatting the same structure: IF XOOS.ALL.COURSES = Y THEN some lines of code END ELSE some lines of code END I can easily see the start and end of both the THEN block and the ELSE block and also easily see to which condition they belong. The same structure can be used for ALL conditional statements and each block is always easy to find and associate with it's starting statement, eg: READU record FROM file,id ON ERROR statements END LOCKED statements END THEN statements END ELSE statements END -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, 28 September 2005 7:11 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Good Programming Practice Question. RETURN with a comment..that is an excellent suggestion. I'd argue that any END statement that's more than a handful (8-10) lines from the opening IF (or whatever) statement should have a comment. Here's an example (that's not long enough to satisfy my 'handful' argument above): IF XOOS.ALL.COURSES='Y' THEN some lines of code END ELSE ;* IF XOOS.ALL.COURSES='Y' THEN some lines of code END ;* IF XOOS.ALL.COURSES='Y' THEN Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 ...our behavior matters more than the beliefs that we profess. Elizabeth Deutsch Earle --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
