Re: Compile error when using field in a subfield data structure

Joe,

<disclaimer> I am not trying to be argumentative, just to offer another
opinion. </disclaimer>

> Or perhaps there simply isn't that much benefit, especially in 
> environments where it is the norm to program in small, readable 
> chunks. It is my contention that procedures (and even subroutines!) 
> are far more of a benefit than indentation.  If your DO loops don't 
> span more than ten lines, it's pretty hard to get lost.  On the other 
> hand, if you have ten levels of indentation, then the chances are 
> you're writing convoluted code anyway.

This really seems to describe code that is written from scratch.  If I
start a new project or program, I typically write in free format
(personal preference), but I do more maintenance than new stuff.  If the
original code had been indented, my first step wouldn't typically be to
compile it into QTEMP to track down what matches what.  I have also seen
200 lines inserted into an if statement that is supposed to do special
processing for a special case.  When I sent the code the DO loop was 10
lines, I get it back at 210.

> 
> 
> > But I did find one publically available study
> 
> A 20 year old study.  Exactly how relevant is this?

The ERP package I spend most of my time in has product updates and fixes
ranging back to '87.  I just saw JDE updates back to 93.  With 17 and 11
years respectively, a glimpse at the study those programmers were using
as a guide can make it easier to follow the code they wrote with that 20
year old study.  

> 
> In a large program.  By which they mean the entire program is one 
> large mainline, a programming practice that went out of style at least

> 15 years ago.
>
 
Tie-dyed shirts went out a while ago too, but somehow some survived.
The same can be true of those kludgy 20,000 line order entry programs.
I can't really go to my customer and suggest a complete rewrite to ILE
because it gives me a headache to read the 900 page spool file.

> 
> > I can personally attest to that, working regularly with both 
> > properly indented C code and with traditional "straight-line" RPG 
> > code. There's no question at all which is easier to work with.
> 
> For you, Hans.  Many programmers find it just as easy to be able to 
> look at fixed-format RPG and be able to read it.  This is a style 
> issue, not an absolute, and there is no sound business reason for 
> moving to /free, especially with the artificial hurdles imposed by the

> RPG team.

I also feel it is easier to work with free form code, but that doesn't
say anything about the rest of my office.  I have personally written
programs in about 10 languages and as a relatively young RPG programmer
(26) I have an easier time reading code that more closely approximates
the languages that I learned with.  I also know that other people in my
office have never seen free format code and I have watched their mind
get blown by using a return value of a subprocedure in an if statement.
I think that the business case will get better as more and more of the
new IT staff get hired that have never seen a columnar language.  Also
some of the disadvantages to free format code seem to fade as the editor
gets better.

Andy