Re: Documenting code changes

A practice I began and still follow is that every time a change is made,
I copy the source member to a new library named with an increment.
Yeah, it's verbose but it allows me to go back and compare between
versions over time. Plus, I comment at the top what was changed and
why. I don't comment out old code, just remove it.

So I might have a QRPGLESRC file with member PAYPROC1 in library
PRBASEV100and then when I need to create a new version I create a
library called PRBASEV101 and copy the source file and member and make
modifications there.

Nothing special but it worked in an organization of about 6
programmers. Probably wouldn't scale. David is the go-to guy for SCMs
so if you have a large shop that may be the ticket.

Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java

On 9/27/2013 10:54 AM, Cyndi Bradberry 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