At the risk of being verbose, this topic is near and dear to me based on the sheer volume of programs and styles I've observed in my many years of MV. While many may offer positive suggestions, I'm sure I'm not alone in offering up code snippets that should be avoided. Remember, nothing is completely useless. It can always serve as a bad example.
1. use spaces after commas in file I/O statements and subroutine parameter lists. especially when so many variables have periods and/or underscores. The white space helps a lot. 2. don't use "L#10 " as the space after the 10 is easily lost and not mentally counted when formatting output. 3. I don't care for IF CONDITION ELSE statement. 99% of IF's are THEN-oriented and sometimes these get overlooked. Use IF NOT(CONDITION) THEN 4. I don't care for consecutive OPEN FILE THEN's with the ELSEs at the end of the program. 5. I don't care for having the NEXT I's or REPEATs hundreds of lines from their starting partners. 3. Use spaces with semi-colons to separate multiple statements on one line. 3. Use common sense when using internal SELECT and CLEARFILE statements. A: If opened and an A-Z select is desired, don't EXECUTE "SELECT FILE" then READNEXT, use SELECT. B: If opened, don't use EXECUTE "CLEARFILE (DATA FILE", use CLEARFILE 4. If you have the luxury of starting a new system or module, put all 3 components of handling the data files in one INCLUDE: A: OPEN FILE to CONSISTENT.FILE.HANDLE else stop B: DIM CUST(100) for this file C: EQUATE CUST.NAME TO CUST(1) EQUATE CUST.ADDR TO CUST(2) 5. If you like using variables as attribute number references, put them in an equate to be consistent as well. 5. Have an INCLUDE that contains all of the necessary housekeeping stuff. 6. Comments are very nice. 7. Revision control using date suffixes instead of <dot>NEW, <dot>OLD, TEMP, HOLD, BKUP, BU etc. 8. Don't use reserved words as variable names, ie COUNT, DATE, PRINT, INDEX, FIELD etc. While these and others are all good suggestions, certainly someone's good suggestion is someone else's caveat and vice versa. If we were to publish a composite of those items that are 100% agreed upon, it would be a very short document. Many of us have seen atrocious code in our travels. This guides us to our personal 'standards' of today. Yet those persons writing this atrocious code may not know there's a better way. I run into some of these guys who defend their poor habits with "That's the way I've always done it" mentality. ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/