![]() |
|
#11
|
|||
|
|||
|
Quote:
![]()
__________________
"Don't tell me how it works, tell me how it fails." |
|
#12
|
|||
|
|||
|
Quote:
If I understood you correctly, I think you missed what I was trying to "say" and couldn't be bothered to write in its entirety. I mean the following type of coding example Code:
Ugh !!!! If only people took the time to realize that almost any IF statement can be made more readable by re-writing it as an EVALUATE statement instead (but that's me). For example, Don's example above (I know it's just an example) could be rewritten as Code:
|
|
#13
|
|||
|
|||
|
I just re-read your original post. If you primary concern is deeply nested IF statements, you may be able to examine the compile listing rather than the code. Column 16 shows you the nesting level of each statement.
__________________
"Don't tell me how it works, tell me how it fails." |
|
#14
|
||||
|
||||
|
Hej Michael,
Well I hacked this together quickly from something else I had from way.back-whenever. It just does some primitive highlighting and it's for REXX (so probably as much use as a chocolate teapot but anyhow..!). The thing that this does is ignore stuff like: Code:
Code:
(this can also be fatal - as anyone who's ever deleted/scrambled their own macro will verify! In this case, being NOTELINEs, its pretty safe). Steve ![]() |
|
#15
|
||||
|
||||
|
Hi - using the compiler listing is a great idea. Does much of the work for you.
I used to have a tool called PLIRITE that could reformat PL/1 based on options. It used the FRMAT option of the (then!) PL/1 Checkout Compiler. So you can tell how long ago that was - late 80s sometime?! I frankly forget exactly when it went "unsupported" (whatever! ) Steve ![]() |
|
#16
|
||||
|
||||
|
Although not perfect either, you can use regular expressions if you want to go to enough trouble to pass the program over to Unix. See my FINDRX edit macro at http://sillysot.com/ftp/findrx.txt
Unfortunately it isn't commented line by line but it isn't very long. I've been through exercises like this before and my approach was the same as yours, but eventually, I end up writing a source code reformatter and run tests against a standard format. Listings sometimes do the same thing (as someone mentioned before) and sometimes compilers have a format function to create new source files. I don't have anything for COBOL though. In my experience, it is beyond any hope of readability so I just do the next best thing; abandon all hope of ever understanding it (... and .. cue another plea not start a holy war).
__________________
New members are encouraged to read the How To Ask Questions The Smart Way FAQ at http://www.catb.org/~esr/faqs/smart-questions.html . |
|
#17
|
|||
|
|||
|
Nja...... Where is the compiler listing, does it even exist ?
I mentioned (?) that I already have a macro - user simply enters NESTEDIF on the command line for any COBOL source code to check that the level of nesting isn't too deep. I've changed the macro to only "count" the word IF/EVALUATE if either one is the first word - I ws just wondering if there was a variation on find that would obviate coding the search in the rexx macro. (The replacement code was only 5-6 lines) |
|
#18
|
||||
|
||||
|
Hej Michael,
As I have said before, my COBOL is pretty stale. However I do play about a bit with REXX. I played about some with calling the compiler and processing the listing. Take a look at this code which seems to work but only reformats the PROCEDURE DIVISION... Code:
Steve ![]() |
![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
|
|