🚀 go-pugleaf

I think your solution to the state problem is a good one and I've used that
solution myself.  The issue I wrestle with is the quick and dirty
compromises I come up with when expressing an idea in a limited space on an
assembler line.

IBM coding standards for assembler on MVS and VM were a comment on every
line.  Common complaints for those reading source are the meaninglessness of
the comments.

I would like users of IBM code to grasp it and be able to exploit what they
understand so that the path to building good apps on top of mainframe
platforms is quicker.

I think, "It's hard to write so it should be hard to understand," is
humorous but not something I like when I'm trying to unravel a problem or
understand a block of code.

Paul Hanrahan

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Robert A. Rosenberg
Sent: Sunday, September 04, 2005 11:02 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Assembly coding guidelines


At 14:25 -0400 on 09/04/2005, Paul Hanrahan wrote about Re: Assembly coding
guidelines:

>Continuing to the next line is useful but not something that should be
>done often.

I was just pointing out that continuing the comment on the next card is a
"solution" to the stated "problem" of the lack of space on the line due to
other required data. If your comment needs to be x-characters long, what is
the difference between it taking up one or two lines (the latter due to
there not being enough room on the first line)?

>
>-----Original Message-----
>From: IBM Mainframe Assembler List
>[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
>On Behalf Of Robert A. Rosenberg
>Sent: Saturday, September 03, 2005 11:00 PM
>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
>Subject: Re: Assembly coding guidelines
>
>
>At 09:39 -0400 on 09/03/2005, Paul Hanrahan wrote about Re: Assembly
>coding
>guidelines:
>
>>What I found the most annoying about coding assembler was the
>>comments. The area for a sequence number and then a code to identify
>>the programmer digs into available space for comments.  Using the
>>comment line for change management identification tied back to a
>>change log at the top of the program in a flower box is a good thing
>>but then with extended opcodes the space on a line is reduced.
>>
>>I like having a programmer id on each line of code for root cause
>>analysis but hate giving up space for line comments.
>
>Throw an "*" in column 72 and you have the next line for more comment
>text. As an alternative, I often throw an "*" into column 1 and
>continue my comment on that line in column 36 (My Start of Comment
>location).