General idea about COBOL beautifying

[Crox]

Hi,

If you look at old sources, updated by many people with different styles, there are sometimes things you like to change.

For example, using the ISPF editor, I try to get all the PIC clauses on one line by repeating this change command, just by entering:

&c ' PIC ' ' PIC ' 10 45 all

Now on all the lines with PIC the word shifts to the right until PIC will start on column 43.

Do you have a favourite column for several words?

Do you have methods to get rid of the old GO TO's?

Do you have ways of giving names to procedure-division names?

Do you want SECTIONS or not?
Do you want GO TO's or not? (what about inverted or recursive programs using JSP techniques)

How are you beautifying sources?

Regards,

Crox

 

[webrabbit]

I have 35 year's experience with COBOL. I don't like GOTOs, Procedure Sections, or Perform ... Thru's. If updating an old program and have carte blanch, I get rid of the GOTOs etc. if I can. There is only one program that I was unable to do so. It had multiple GOTOs jumping from and into the middle of perform loops. I never could figure out how it actually worked, although it seemed to.

I am now using Microfocus COBOL, and an editor that can switch the screen to 60 lines by 132 columns. Microfocus has an option for "free format" source code which removes the line number columns and extends the line width to 255. Line numbers are from the old days of source code on cards. They were essential then, useless now.

I use initial caps for COBOL reserved words except "and", "or", "not", "in", "of", "is", "with", and some others, which I write all lower case. All user-defined words I make all caps.

I line up "Pic" in column 34, and "to" in the leftmost column I can in each paragraph. I line up "from", "by", and "using" right-justified with the "to"s

I use a 3- or 4-digit paragraph name prefix, using structure chart number for the prefixes. I try to avoid 4-digit prefixes, but will even expand to 5-digit if the program is complex enough. I try avoid complex programs.
Most programs I write are 200-600 lines long. I use an alpha character in the prefix if it is a routine common to two or more paragraphs, the alpha character being at the point of commonallity. For common general-purpose routines, especially those in copybooks, I do not use a prefix and put them at the end of the program source.

By using 132 columns for source code, I can almost always have each statement on one line only, and almost never have to continue non-numeric literals. (The makes report heading lines very easy to read and modify.) Since free-format source can be up to 255 columns wide, I sometimes make report headings extend past column 132 is they are complex enough, although I try to avoid that if it makes sense, even moving the "Pic"s to the left.

I make my picture strings X(nn), 9(nn), S9, S9v99, and 9(nn)v99 whenever possible. I don't like 3-digit repetition factors, and use them as sparingly as possible. I make picture characters that don't reserve space such as "v" and "p" lower case. (I make "S" upper case as it is always the first character in the string.

I put "Value" in column 44 for "88"-levels; and in column 34 for "78"-levels, if you know what those are.

I always use "End-" for conditional verbs and line up the "End-" with the verb, and "Else" with "If". I don't put periods inside paragraphs, nor do I ever use "Next Sentence".

I try to make my procedure paragraphs fit entirely on the screen, which is pretty easy with a 58-line screen (or even a 48-line screen that most text editors can support).

Back in the mainframe days, I always tried to use a 3270-5 or a -4 for editing.

 

[slade]

Hi,

I worked for a guy that reviewed all change code (we used Endevor that hilighted changes with a "%" in the first column of each change line) and would reject any changes not directly related to the assignment.

His point was well taken: These kinds of cosmetic changes can cause production problems with consequences that far outweigh the benefits of the "beautification".

Well, it was his sandbox and I did it his way.

On another front, while I agree that GO TOs can make a program hard to maintain, I'm not a GO TO bigot. In certain circumstances a GO TO can simplify code (gasp!). I like to use them at the start of a pgraph to help the reader decide if (s)he has to continue in it. Of course, that leads us to the "T" word, THRU (gasp2!).

Oh well, just my opinion. I listen to all these discussions about GO TOs, et al and I begin to see how some religions began to miss the point of their own teachings.

Not using periods to end sentences in a pgraph has saved me from many errors when copying code into an IF stmt.

In addition to aligning PICs and using X/9(nnn), I also like to offset the PICs of a REDEFINE. I find it simplifies the task of quickly calculating the offset to a field in a group or its length.

I like to present the major loop logic of my pgms first and the one-time stuff last, so my init routine is usually numbered 8000-... to force it to the end of the code.

When documenting the code I eschew the obvious and generally try to focus on the “business” intent of the detailed code. For example, I may have a 10 or 15 stmt sequence that moves, compares strings inspects, blah, blah, blah. But 2 English sentences can explain its intent. If the intent of the code is obvious, don’t bother. I came across the following at one account, I kid you not:

	*         PROCEDURE DIVISION
           
     PROCEDURE DIVISION.

Amazing!

I also noticed that pgraph documentation can get lengthy, so I experimented with putting the bulk of it after the last line of code in the pgm. For example:

 3000-EDIT-INPUT-REC.
*THIS ROUTINE....(a short description)
*SEARCH FOR “*3000-EDIT-INPUT-REC COMMENTS” FOR MORE DETAILED COMMENTARY

The intent was to provide info for those who needed it, while keeping the code terse and easy to navigate.

Regards, Jack.

 

[ceh4702]

GO TO'S are irrelevant in my opinoin. Replacing them for the hell of it serves no purpose. I never exclusively use GO TO's or Performs. Sometimes GO TO's work better and sometimes performs work better. A badly written program can be just as hard to follow if it has too many perform statements in it.

You left out GO TO . . . DEPENDING ON.

If you are checking for errors GO TO is a very efficient way to code. People will disagree, but too bad. If you do not like my post feel free to point out your opinion or my errors.

 

[MarcLodge]

I've used GO TO's when wanting to branch to the exit, but that's about it. Most sites have thier own rules and the majority of them ban GO TO's. Back in the old days I remember many a program reading a file with a variety of record types and GO TO DEPENDING ON REC-TYPE.

I also worked with a chap once who was told that ALTER was not allowed at the installation. This was like a red rag to a bull, and he took it upon himself to write one into his next program.

I think that most of us will have our own personal preferences built up through many years of experience. The trick is being sensible enough to go with what the current site's standards, not your own.(even thou quite often you KNOW yours are better!)

Marc

 

[Crox]

Thank you! But don't let this stop anybody!

Webrabbit, goto's jumping out and inside sections, are using the fact that a performed section keeps having a 'hot' end-of-section. So if you leave an eactive section with a GOTO and later on you jump again in such a section, there is still a hidden goto at the end of the section, jumping to the next statement after the perform. If the section wasn't performed, you get a drop trough to the next section..... It can work but it is a very bad programming practice.

Slade, would that guy that doesn't agree with cosmetic changes, accept a program that does these kind of things?

Marc, goto depending on's are very efficient when you invert programs for example.

Regards,

Crox

 

[slade]

Crox,

I guess his attitude was "if it ain't broke, don't fix it". If the "ugly" code caused the problem you were assigned to fix, I guess he'd let you "beautify" it. And he'd say something like "beauty is as beauty does."

Regards, Jack.

 

[webrabbit]

Using goto to exit the paragraph? That is what "EXIT PARAGRAPH" is for!

 

[3gm]

Unfortunately, EXIT PARAGRAPH is only available on a limited number of COBOL implementations. :-(

Glenn

 

[Lunker]

I had never seen EXIT PARAGRAPH until I read it in the previous post. Unfortunately, it appears to me to be a Micro Focus feature. It's not in my IBM manual.

I've been programming in COBOL for 28 years. Started before structured programming was advocated. Our shop developed our own standards. We started with all of the rules that were recommended by the experts and wrote programs over and over deciding what was practical and what was not.

One of the things we decided was that the GO TO was a useful tool and when put in the right place, did not cause trouble. Every paragraph we write has an exit.
3000-PRINT-DETAIL-LINE.
.
.
.
3000-EXIT.
EXIT.

The only statement allowed in the exit paragraph is exit. We always Perform thru the exit. Notice, the exit paragraph has the same prefix as the main name so we are not allowed to insert other paragraphs in between these. So the reason most of you avoid the THRU option doesn't apply here. If we are ever inside of 3000 and decide we are done, we are allowed to GO TO 3000-EXIT to end the perform. We can't go to 3000-EXIT from anywhere else in the program. We feel the use of this GO TO saved a lot of ugly nested IFs that caused the logic to be hard to understand.

We're also allowed to GO TO 3000-PRINT-DETAIL-LINE from anywhere inside of 3000 to cause a loop. We rarely use PERFORM UNTIL for that purpose. It goes way back to what preferences were when we developed the standards.

Generally, when you're looping you're going thru a sequential file processing all of the records. You may wonder why not PERFORM...UNTIL END-OF-FILE. One reason is because, for maintenance, we allow only one READ for a file to be coded. If any changes are needed there is one place to fix. Therefore, the READ is at the start of our paragraph loop. There is no priming READ like many do. So if we read at the start of the loop and did not have the GO TO exit available to get out when we reach the end, we would have to nest the entire paragraph.

You might think these standards are hard to get everybody to agree upon. Not really. We very rarely, if ever, hire experienced programmers here. We get new college grads, most of whom have never used COBOL since they've been taught for years that it is a dead language. I teach them all the way we do things here and that's the way we code. Generally, you can pick up a program written by any one of the nearly 100 programmers here, and it looks very much like something you would write yourself. It makes the maintenance task much simpler.