Kevin:
Believe it or not, READABLE. Many of the code I inherit isn't even indented.
BFORMAT or FORMAT cleans up so much.
>From there, remove commented code lines and archive the evolution of the
current version. That alone removes a lot of the clutter that is in the way.
At that point the program might make some sense. If the majority of the app
is written with a programmers limitation, then brace yourself for many
recurring shortcomings.
I use a program called MAKE.OPENER that replaces the huge variety of OPEN
statements with their war & peace errmsgs with CALL OPENER("CUSTOMER",
F.CUSTOMER). That makes that section much cleaner.
Use INCLUDES for COMMON blocks and housekeeping sections of code.
Use INCLUDES if you choose to use equates as alias's, for consistency.
Have comments illustrating what each labeled section is doing.
Steer clear of renaming live programs as UPDATE.NEW, UPDATE.V2, UPDATE.NEW2
and likewise archived programs as UPDATE.OLD, UPDATE, BKUP, UPDATE.HOLD.
Keep the live version as UPDATE and datestamp all the archives in a separate
file, ie BP.ARCHIVE UPDATE_093005.
I'm sure I'll have more as will many others.
My 2 cents.
Mark Johnson
----- Original Message -----
From: "Kevin King" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 30, 2005 10:04 AM
Subject: RE: [U2] Programming Metrics (was "Good Programming Practice
Question.........")
> Can we shift this discussion just a bit? Rather than address specific
> programming practices, what are some metrics that you use to define
> what is "good" in your environment?
>
> -Kevin
> [EMAIL PROTECTED]
> http://www.PrecisOnline.com
> -------
> u2-users mailing list
> [email protected]
> To unsubscribe please visit http://listserver.u2ug.org/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
