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/

Reply via email to