Re: COBOL ain't quite dead - yet !


Richard <riplin@xxxxxxxxxxxx> wrote in message
news:18e8bb27-c836-4a0e-b611-04c111a41ee8@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Oct 30, 10:12 am, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"Howard Brazee" <how...@xxxxxxxxxx> wrote in message

news:747hg4965hgegcuojhe10um7ic1f5lnccg@xxxxxxxxxx

I have seen

PERFORM AAA THRU AAA-EXIT.

AAA SECTION.
AAA-PARAGRAPH.
...
AAA-EXIT.
EXIT.

The problem with that it that breaking down the sections in a logical
way is too much effort. Putting in a paragraph label is a lightweight
solution that makes you feel that the code is properly structured when
it is not. The style of having 3 labels and an EXIT for everything
makes it too laborious to properly compose, the style gets in the way
of expression.

Not if you're used to it. See your own comment below.

Unreferenced paragraph labels (ie drop-through) causes additional time
for the next programmer who has to check whether this would cause a
logic change. For example if the PERFORM had been done in error to the
first paragraph name instead of the section name then the spurious
paragraph label would end the perform while a comment line would not.

Having the section and first paragraph labels 'costs' the possibility
of the wrong one being performed. Having an exit label 'costs' the
possibility of errors such as goto the wrong one, or having a goto
added when the paragraph was performed in error.

Some of those errors would still have the program perform perfectly
_until_, for example, a goto exit was added.

As the only validation for the correctness of the style is by visual
inspection of the whole program then it is not a style that I would
use.


The possibility of the errors you mention is obviated by testing, isn't it?
Surely you don't think that people using this style don't perform the
obvious checks? As for the "correctness of the style" - I don't fully
understand what you mean by that; it strikes me as an esthetic matter rather
than a functional one - there are tools to format the listing, to flowchart
it, to determine execution paths, to show the usage of labels. A purely
visual inspection of any non-trivial program would be too laborious and
error-prone to trust.


What is 'easy' is entirely what you are used to. When one writes code
in a particular style one knows exactly the idiom and thus makes no
(or fewer) mistakes. I have worked on code that is as you describe
that had many errors and bug-traps. It was obvious that some other
programmer had later worked on the code and didn't understand the
idiom, or didn't adhere to the style correctly.


So it wasn't the style that was to blame, was it? Just as you say, "What is
'easy' is entirely what you are used to.".

My opinion is that the only persons qualified to judge styles are the ones
that have worked with many. Many times I have had to maintain or make
changes to programs written in styles that I didn't like, but by conforming
to that style I almost always did the job properly and learned something in
the process. I STILL don't like goto-less programming but I'm not about to
say that it shouldn't be used for that reason.

(My one unsuccessful maintenance experience was on a program that neither I
nor the previous SIX people that tried could understand how it worked at
all. I gave up and rewrote it).

PL


.