Re: Documenting code changes

I agree strongly that this thing of marking code when we change it does
nothing but make it extremely difficult to read or maintain the code.

Even if you don't have a full blown change management system every shop I
have been has something that makes a copy of source member and archives it.
Every system has a PDM option 54 to compare source and see what has
changed.

Marking up the code is not the solution.


On Fri, Sep 27, 2013 at 9:54 AM, Cyndi Bradberry <CyndiB@xxxxxxxx> wrote:

Hi,
In the past, we have documented at the top of the program the date, ticket
# and a description of a change. Now we are being told to put the ticket
number in the first 5 positions, copy the line we are changing, commenting
out the original line and editing the new. In CLP, /* */ to enclose the
ticket number on the line being changed.

But I cannot get anyone to explain how long this remains in the code. I
don't have a problem with commenting out and entering new lines, but when I
go in to maintain the program next, I generally want to clean up (delete)
the unused lines of code to make for better readability. When making large
changes, I also make backup copies of the source member just in case I have
to go backwards.

Can anyone point me to a best practices for documenting code changes ?
This would have to cover RPG IV and Free and CL programs. We are working
towards a SOC 2 Type 1 compliance.

TIA,
Cyndi B.
Boise, ID
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.