Re: Infinite Loops and Explicit Exits

From: Robert Wagner (spamblocker-robert_at_wagner.net)
Date: 11/06/04 

Date: Sat, 06 Nov 2004 05:33:56 GMT

On 5 Nov 2004 11:08:22 -0800, riplin@Azonic.co.nz (Richard) wrote:

>Robert Wagner <spamblocker-robert@wagner.net> wrote
>
>> Bad code is difficult to understand and to maintain reliably.
>
>How easy code is to 'understand and maintain' is primarily a function
>of how familiar the maintainer is with the way it is written. It is
>to do with expectations, being able to rely on assumptions, knowing
>where particular code fits and where to find it.
>
>This is why site standards are so important to most companies. If all
>programs are written the same way then one can pick up a program that
>hasn't been looked at for decades and can understand it immediately.

I concur.

>Of course that does stifle progression, but the company is there to
>run the business, not write books on style.

I disagree. Style can be refined in an EVOLUTIONARY (not
revolutionary) way without deprecating what came before. In the world
of cinema, such progression is called 'auteur theory'.

>The main problem with adopting the very latest trendy styles (or even
>'what C did in the 80s') is that the systems become fractured into
>'old unmaintainable' and 'new trendy' with various intermediate and
>experimental styles between. So do the programmers. Individuals
>become tied to certain styles because they can easily and reliably
>work with programs they understand.

If change is gradual, the same themes appear in old and new code.
There isn't a scism or fracture. A weak but current example is
replacing GO TO THE-EXIT with EXIT PERFORM.

>As programmers turnover the old systems become unmaintainable, not
>because the style is inherently unmaintainable, but because the
>programmers are unused to it, or more likely, unwilling. This reduces
>the value of the system, makes it expensive to maintain (at the charge
>rate that Doc would like to ask for), and/or would require
>replacement.

That's why it's important to start with ALL programs in a good style
and no Old Style programmers on the staff. When people are growing,
they are eager to advance. The unwilling and resentful are those stuck
in a rut.

In 20 years as manager, not a single programmer resigned during my
watch. I like to think it was because they were constantly challenged
and encouraged to improve the status quo, rather than follow
nonnegotiable rules.

>The way that companies retain value in their investment is to set
>coding standards that keep the programmers producing consistent code
>so that even the oldest programs can still be easily maintained by any
>of them.

The best standards are formed by consensus rather than fiat. In my
shops, every programmer could work on every program. To make the point
there were no territories, I told them 'If you write a program today
and it needs maintenance three months hence, the task will NOT be
assigned to you, it will be assigned to the person sitting next to
you. If he or she sees a way to improve your logic, I'll encourage
him or her to do so, even if it is outside the scope." Their
motiviation was pride .. in the eyes of their peers; not getting their
hands slapped by The Boss. After a few iterations, you couldn't tell
at a glance who wrote a given program. They had a consensus style that
was better than any one individual could have mustered. That's called
synergy.

>Otherwise they wind up with a bunch of coders rewriting the whole
>thing to do exactly the same job in some new-fangled way at huge
>expense with no site standards, and then find that commodity
>programmers can't reliably maintain it and have to rewrite it all over
>again back to follow some standards.

Fear mongering. I've described how it worked at 4-5 places I managed.

>> Cause: failure to use .. typedef.
>
>How can you possibly criticise them for not using a feature that is
>not available in their compilers ?

Typedef is available on Micro Focus and Fujitsu.

>> .. Decision made in one place, action based on the decision taken far
>> away .. in the same or another program.
>
>Decisions and actions must always be made in different places, it
>can't all be in one line of code.

Not one line of code, one PLACE. Example:

IF condition
    action
END-IF

>Tax rates may depend on where the
>delivery is made to, you can't decide where the delivery is to be in
>the tax calc, nor would you calculate the tax in the address code.

So you join delivery-address, taxable-sales-amount and tax-table in
one place that isn't subordinate to any of the three. In OO, it would
be a method of tax-amount.

>> .. monolithic programs.
>
>How can 'monolithic programs' be the cause of something 'in another
>program'. Monolithic means there are no 'other programs' - mono - get
>it ?

I said "far away .. in the same or another program."

>> .. Code that "does what it's supposed to" when presented with
>> anticipated cases but produces 'undefined results' for unexpected
>> inputs.
>> Cause: unstructured programming.
>
>It has zero to do with whether the code is 'structured' or not. The
>best structured code can still produce 'undefined results' if the
>specification for the program does not specify what results should be
>given for those inputs.

A well-written program should log and bypass cases it doesn't know how
to handle. They represent a 'bug' in the specs.

>> .. Code that abends without reporting the case (record) or reason.
>> Cause: laziness.
>
>One could argue that a program should never abend. If the programmer
>could predict what would make the program fail and thus surround it
>with reporting code, then he could make the changes necessary to stop
>it abending, and thus the reporting is superfluous.

I have argued exactly that. Mainframers don't buy it. They say no one
reads logs, the only way to get attention is to abend. It's a cultural
issue.
 
>> .. Inconsistent naming of variables such that a global search misses
>> references.
>
>Consistent naming is usually one of the things that are in the site
>standards that you seem to deride.

To that end, one of my rules is 'no abbreviations'. I routinely use a
spellchecker on programs.

>> .. Flow of control that's difficult to follow.
>> Cause: unstructured programming, weak logic skills.
>
>This relates back to the first point. What is 'easy' and what is
>'difficult' is entirely dependent on what one is used to and what
>one's expectations are.

Partially true. Nobody finds spaghetti code easy to follow, even those
accustomed to it.
 
>> .. Awkward conditional logic.
>> Cause: weak logic skills.
>
>What is 'awkward' to one is 'simplified' to another. The advantage of
>writing in a style that assumes the reader has 'weak logic skills' is
>that when the assumption is correct at 2am the job can still be done.

At 2AM is when concise logic is needed most. Code that trips over
itself is annoying at 2PM, impossible to follow at 2AM.

>> By that definition, supporters of Old Style Cobol are reactionaries.
>
>Now you will probably characterise me as a 'supporter of Old Style
>Cobol'.

No. I agree with you on single-paragraph performs, no go tos nor
exits.

>In fact others think that I don't - as is obvious from other
>posts. What I do understand is why companies want to protect their
>investment in the code that represents and runs their business. They
>want code to last as long as their business will and so they want it
>done conservatively and they want their programmers to be equally
>conservative.

What's needed is a body of programming that can make changes as
rapidly as management demands them. It it cannot keep up, it will be
replaced by another technology.

When the rate of change is slow, it is rational for the programming
culture to be conservative i.e. resistant to change. But conservatism
is misplaced when it opposes the company's growth, and its adherents
will lose sooner or later.

>We have all heard stories about how a bunch of maverick programmers
>rewrote all Cobol into some style that average coders had difficulty
>with. This forced it to be rewritten again back into a rational style
>with site standards but the company was driven into bankruptcy ;-)

The stories I've heard were about Cobol replaced by Rapid Application
Development in another language .. because the shop's Cobol culture
couldn't keep up.

>By and large the companies will also be slow to update to the latest
>technologies. They adopted '85 compilers when forced to, they,
>generally, did not rush into OO, because there was no final standard.
>They will move to '02 compilers some years after they become available
>(if they do).

Some industries go too far the other way. Financial Brokerage rewrote
major apps in Smalltalk in the '80s. By mid-90s they had
third-generation non-procedural code.

Many big companies have replaced most Cobol with an ERP such as SAP,
PeopleSoft and Lawson.

>Your strategy of attacking the programmers and calling their code
>'bad' and requiring a revolution is flawed. You just annoy them and
>make them resolute that they don't want no stinkin' 'real programmers'
>here.

Bad ones have always been defensive; good ones aren't annoyed or
threatened.

Relevant Pages

  • Re: help with tables
    ... Compare these two statements about Cobol old timers' capacity for meanness ... Maybe you violated their standards, ... It doesn't come from management, ... In some shops they hurriedly 'modernize' the standard to describe the obsolete practices ...
    (comp.lang.cobol)
  • Re: Further discussion on "Something has to be maintained" and lack of OO acceptance.
    ... various standards committees took to define, ... INTELLECT (the one I wanted but management were not interested). ... The resistance came from the Priests of COBOL, ... if the IBM mainframe world had been forced to use the screen ...
    (comp.lang.cobol)
  • Re: If you were inventing CoBOL...
    ... It seems arrogant for mainframers to impose their ... >> norms on everyone else, ... It depends on the application and shop standards. ... are not supported by standard Cobol. ...
    (comp.lang.cobol)
  • Re: Perform forever
    ... both of you MIGHT be interested in how the Standards ... committees are TRYING to add "native" syntax to COBOL to handle all of this. ... > IF TAG THEN ... >> objection to that that Richard does. ...
    (comp.lang.cobol)
  • Re: Time for a historical question Black five versus Ivatt BR 4-6-0
    ... So that is where my antipathy towards the BR Standards comes from. ... They may have been worthy locomotives, ... At the end there were some small tank engines replacing the ... from Paddington to Bristol. ...
    (uk.railway)