RPG and Programming

#1. And the best reason to code in free-format syntax is: We can finally see the structure of our code as we work with it!

Just a few more words on that last point. Free-format is just that - free. A programmer can choose to start a statement in any column after column 7 and continue through to column 80. So nested logic can now be indented, allowing us to craft code that conveys an immediate and intuitive sense of the order and conditions of execution. Nested fixed-format code can be difficult to work with, and if it’s deeply nested it can be an outright nightmare. This problem is removed in free-format RPG. Properly indented nested control structures tell the story at a glance. It simply takes less mental energy to understand the intent of well-written free-format code.”

Before we go too deeply, note the use of “weasel” words. Weasel words are words that you can use to show, if someone questions you on the validity of a claim, that you qualified it so that it didn’t say what he thought it said. (I learned the expression in a book on advertising.) Note- nested fixed-format CAN BE (not IS) difficult to work with. PROPERLY INDENTED (not ALL) control structures tell the story at a glance. And the reference to WELL-WRITTEN free-format code. This allows you to say that if the nested code is obscure, it was not properly indented or well-written. Somewhat different than the common unqualified claims that free-format code IS easier to understand.

We are not under the illusion that what follows will convince people to use fixed format instead of free-format RPG. What we do hope is that a free-format advocate will look at the whole situation with a more open-minded attitude than he does now, that it is not an open-and-shut case that free-format is easier or more usable.

But to proceed:

1. Note that word “intuitive” used again. As with our previous posts, we ask: Intuitive for whom? And the answer is the same- intuitive for the person who has been trained on block-structured code.

Brian Kelly, a noted ex-IBM Systems Engineer, author, and lecturer, gave these comments in a discussion of what he did and didn’t like about RPG IV:

“Hey, I liked RPG IV when it came out with the larger field sizes and the D: spec and the date operations. I am not as fond of the new RPG with its ILE connotations, difficult to understand procedure prototyping, and Java like built-in functions. I would have been happy without those. I liked being able to debug a customers code by looking on the right side of the RPG page looking for where a variable was changed or an indicator was turned on.” In other words, he liked fixed format, where he could expect to see result fields and indicators on the right side of the page. Free-format is not so easy or comfortable for those who are used to fixed-format code.

But perhaps you would expect that. These old stick-in-the-mud, died-in-the-wool coders are just too set in their ways, aren’t they? So let’s look at it a little more deeply.

1. Is your free-format code done the right way?

   I came across this discussion of indentation style for Pascal. It was written by a Pascal programmer who, by his own assertion, had written, as the document was written, close to a million lines of Pascal code. Note his example of good and bad code, and why they are so:
   “1-60. The value of “3″ and the injunction against “double indentation” saves space and makes the result more readable. Consider the following two examples:

 bad:
   for i := 1 to 10 do
       begin
           buf [i] := 0;
           foo [i] := 0;
       end;
   if ktr = 0 then
       begin
           if not done then
               begin
                   ...
good:
   for i := 1 to 10 do
      begin
      buf [i] := 0;
      foo [i] := 0;
      end;

   if ktr = 0 then
      begin
      if not done then
         begin
         ... 

Many Pascal programmers have seen the “double indentation” style because the professor in charge of UCSD Pascal (in the early 1970s) used this style. Note that he was primarily a teacher, not a programmer.”

1. Did you notice the differences? The “bad” is indented between “begin” and “end”, the “good” one isn’t. The author feels that his way is better and more readable. Perhaps it is for some. But the alternative “double indentation” style was used by one of the early professors who taught Pascal in the early 1970’s. Wouldn’t you think he would be making every effort to make Pascal easy to read and comprehend? We suspect that the students of that professor had no difficulty understanding him and used his style, as students do, found absolutely nothing wrong with his way of coding, and now find the other way deficient.

What’s the point? Whether a particular technique is good or bad largely depends on how you learned it. There was nothing intrinsically wrong with either technique. And is the other technique unlearnable because the first one was learned first?

Do you think Brian Kelly or I have any problem with opcodes lined up in a row with fixed-format RPG? No, we consider it a virtue. We can look right down a column and see what is going on. Any new RPG programmer could learn to do that, if he chooses, just as easily as we did. Linking IFs and ENDIFs are automatic for a skilled coder. (Nothing is easy for an unskilled coder.) If your prejudice against fixed-format blinds you to other skills, that is an indeed an issue that you will have to address- that is, if you expect to be hired to maintain the vast majority of the hundreds of millions of lines of RPG code that exist today and will not go away just because you wish them to.

A secondary point would be, is RPG free-form really free form done right?

Note the remarks of Bob Cozzi, noted author on RPG topics, when freeform RPG was first created within RPGIV: (His views have changed somewhat since then, but his comments are still instructive:)

“For the most part, and to IBM’s credit, the syntax is no where near as poorly designed as the first half dozen or so attempts at it. The syntax, at first glance appears to be reasonable consistent within

itself except for requiring conditional statements (IF, ELSE, FOR, etc.) to be terminated with a semi colon also. Is it me, or is this ugly?

 /FREE
              If  Price > 0;
              Eval   Price = Cost + MarkUp;
              elseif Price < 0;
              Eval   Price = 0 + MarkUp;
              elseif Price = 0;
              Eval   Price = MarkUp;
              endif; 

          /END-FREE

I wonder how many times I’m going to leave off the ending semi colon on the IF and ENDIF statements? I can tell you now, every time I write that code. Hence I will not be using /FREE directives for the foreseeable future.”

3. Is indentation really all that helpful?

This is a slam-dunk for most writers on the subject. Of course it is, they say. The problem we have in understanding the real situation lies in those lovable 10-12 line snippets of code that show three levels of nesting, clearly identified, easily visible. That does not represent the real world of programming.

Please join me in a thought experiment. ( I don’t want to insert a 500-line program in this post – it’s more than long enough already.) Remember that a green-screen contains 24 lines per screen; a Windows editor, perhaps up to forty lines per screen, and a compiler listing, about 55 or so printed lines. Imagine what the following code looks like:

If x=5 and y=4
  (10 lines of code)
  if total > 2000
    select
      when empdept<10
        (25 lines of code)
      when empdept<20
        (40 lines of code)
        if employee#=255
         (5 lines)
        else
         (45 lines)
        endif
      when empdept<30
        (60 lines of code)
      other
        if salary<55000
          (10 lines)
        elseif salary<75000
          (230 lines)
        else
          except    error
        endif
      endsl
    endif
else
  if   z>36
   (40 lines of code)
   except error
  endif
endif
 

I hope you are getting the point. Code like this is not at all unusual. Proponents of free-format would probably like to slice and dice this code, stick code in subroutines or subprocedures, and break up the structure somewhat. But that would be an evasion of the issue. It is not really all that bad, I believe; no indicators in the way; there are no hindrances to understanding; it is indented properly (I think; it’s hard to tell with a long program).

The problem is, of course, that at any given point you are likely to lose track of where you are. Indentation is no help here; if you can’t see each end (IF-ENDIF; SELECT-ENDSL, etc.), you have no way of “getting your arms around” the code at any given point within the code. (Remember the size of the screen or page.) Even if both ends are visible at the top and bottom of the screen, but there is nested code inside and another level above it, it is difficult to tie the ends together. Of course, there are editing tools in WebSphere and Code400 to tie the ends together- but they work with fixed-format code too, so there is no advantage of free-format there. You can’t see the structure as you are working with it; you have to, so to speak, stand back and look somehow at the larger view.

The point is, in real-world code, free-format indentation is of little benefit. You may say that you would have the same issues with fixed format; that is true. And that is exactly the point.

1. What about maintenance?

   Suppose you have created your long program in RPG freeform. It works beautifully. It is put into production. It is flawlessly indented. You know that if you work on it again, you will take care to make sure it will continue to be indented properly. A year goes by; you have left the company or are working on another project, and changes need to be made. Another programmer is assigned to make the changes. He respects your free-format code, and he writes free form too; but he is not so diligent about indentation. Where you have it indented 10 spaces, he indents 6. He adds about 30 lines of code. What can be done now?

   The fact is, nothing. What understanding you once could get from indentation is now ruined if no one goes back in and fixes the indentation. You may say there should be a standard that programs should be indented properly. But what if he ignores the standard? What could be done? One RPG guru spoke with disapproval of a programmer being fired for writing an RPGIV program in a shop where RPG/400 was the standard; one wonders whether he, if a manager, would be forgiving of a coder who ignored the standards of indentation.

   The fact is, indentation is optional; as far as the compiler is concerned, indentation is simply eye candy. The perceived benefits of indentation are easily negated if programmers are not rigorous in their indentation.

   To my mind, the only computer language that treats indentation in an intellectually honest manner is Python. Python has no “End”s. The logic is entirely determined by nesting. A sample (quoted from the online tutorial on the Python web site www.python.org):

   
   >>> x = int(raw_input("Please enter an integer: "))
   >>> if x < 0:
   ...      x = 0
   ...      print 'Negative changed to zero'
   ... elif x == 0:
   ...      print 'Zero'
   ... elif x == 1:
   ...      print 'Single'
   ... else:
   ...      print 'More'
    

   The original assertion at the outset was:

   We can finally see the structure of our code as we work with it!

   Just a few more words on that last point. Free-format is just that - free. A programmer can choose to start a statement in any column after column 7 and continue through to column 80. So nested logic can now be indented, allowing us to craft code that conveys an immediate and intuitive sense of the order and conditions of execution. Nested fixed-format code can be difficult to work with, and if it’s deeply nested it can be an outright nightmare. This problem is removed in free-format RPG. Properly indented nested control structures tell the story at a glance. It simply takes less mental energy to understand the intent of well-written free-format code.”

   In the real world, we may not be able to “see the structure of our code as we work with it”, either because the code is so long or because the original programmer or his successors were not diligent in their indentation practices. Whether the code that has been crafted “ conveys an immediate and intuitive sense of the order and conditions of execution” may depend upon the source of your intuition as well as your skill of execution. Nested code of any kind can be difficult to work with and a nightmare if deeply nested. This problem is NOT removed in free-format RPG. “Properly indented nested control structures” MAY “tell the story at a glance”- if your program is less than 30 lines long. Beyond that, there are no guarantees.

This entry was posted on Saturday, June 28th, 2008 at 7:17 pm and is filed under Brian Kelly, Programming, Python, RPG, RPG Freeform, RPGIV. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.