Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?

On Tue, 19 Jul 2005 11:02:50 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxx> wrote:

>
>"Howard Brazee" <howard@xxxxxxxxxx> wrote in message
>news:dbge55$gm2$1@xxxxxxxxxxxxxxxxxxxxxxx
>>
>> On 16-Jul-2005, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote:
>>
>>> Ansolutely :-). I wouldn't take the bet. Removal of duplicated code is a
>>> very good benefit of structuring (whether a human gets to see/maintain it
>>> or
>>> not :-))
>>
>> I've worked in environments where duplicated code was desired.
>
>I'd be interested to know what those environments were, Howard. Never
>encountered it myself, and am having great difficulty imagining it.
>
>
> >So I'll play
>> Devil's advocate here and ask why an automated system should significantly
>> benefit by eliminating duplicated code.
>
>A very fair question. If no human is going to maintain it, you could well
>argue that duplication is irrelevant. However, it isn't . Here are some
>reasons why even a code generator might avoid duplicated code:
>
>1. Isolation and reuse of functionality. Refactoring code into component
>functions means that the code can be shared and reused. Even if you are not
>maintaining it, you might want to export the functionality to other systems
>or include it in new features of existing systems. (This is the main
>advantage of component based systems.)
>
>2. The less code that is generated, the faster it will run.

Not necessarily. Some of the wild optimizations of IBM's mainframe
COBOL include moving the code for PERFORMed paragraphs inline
replacing the PERFORM depending on how many places the paragraph is
PERFORMED from. I am certain that the same exists in other compilers
for various languages.
>3. It is easier to maintain an inventory of discrete functions if their
>functionality is not duplicated all over the place.

This is true. This gets into a whole host of questions on tradeoffs
on maintainability, control of introduction of new functions, the
efficiencies of compile time versus bind time versus run-time binding,
especially with parameter checking. NOTE CLEARLY, this is not an OO
versus non_OO question since run-time binding is being done in a large
percentage of z/OS COBOL shops today (all CALLs use the DYNAM option).
>> rest snipped
.

Relevant Pages