Home > Archive > Cobol > March 2007 > Help! GO TO and PERFORM THRU!
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Help! GO TO and PERFORM THRU!
|
|
|
| Okay, so I have been doing the Cobol thing for a couple of months now,
Unisys, DMS2, datasets, batch, BOLTS screens, etc. and quite enjoying
it. However, it appears our S&P manual states we are to use GO TOs,
and my fellow Cobol programmers use them, as well as the PERFORM THRU
statements.
Okay, they use them pretty cleanly I'd say. PERFORM A100-READ-FILE
THRU A100-READ-FILE-EXIT, etc. and the GO TOs are only used to loop
through reads and writes and such, and to go to the exit paragraphs
upon errors, or maybe in a nested loop to go back to an earlier loop.
It's not exactly spaghetti code (or is it?) , and it's 'the way it's
done' where I work, so I'm just following orders. This is my first
programming job, went back to school in my 30's, been toying with
programming since 7th grade, having lots of fun too.
So, if you are going to use PERFORM THRU and GO TO this seems a
halfway decent way of using them. But I believe I have some choice in
how I proceed in writing my code, S & P manual may be out of date, but
I haven't really discussed this much with anyone.
I have been reading much trashing of PERFORM THRU and GO TO this
morning, and I'm just curious what opinions people have. Obviously, I
will do things the way my company wants them done, but I will have
some flexibility in future programs, so I'd like to start thinking
about it now.
Thanks
Impy
| |
|
| Okay, I've been reading through old posts, looks like this has been
pretty much thoroughly covered, so that's interesting. I will test the
waters to see if I can NOT use PERFORM THRU and drop the GO TO, but if
not, I'll try to keep it neat.
Thanks
Impy
| |
|
| --------------------------
Sorry, I replied to myself and the posts got melded together. I think
I've read enough on this subject, but thanks.
--------------------------
| |
| HeyBub 2007-02-24, 6:55 pm |
| Impy wrote:
> Okay, so I have been doing the Cobol thing for a couple of months now,
> Unisys, DMS2, datasets, batch, BOLTS screens, etc. and quite enjoying
> it. However, it appears our S&P manual states we are to use GO TOs,
> and my fellow Cobol programmers use them, as well as the PERFORM THRU
> statements.
>
> Okay, they use them pretty cleanly I'd say. PERFORM A100-READ-FILE
> THRU A100-READ-FILE-EXIT, etc. and the GO TOs are only used to loop
> through reads and writes and such, and to go to the exit paragraphs
> upon errors, or maybe in a nested loop to go back to an earlier loop.
>
> It's not exactly spaghetti code (or is it?) , and it's 'the way it's
> done' where I work, so I'm just following orders. This is my first
> programming job, went back to school in my 30's, been toying with
> programming since 7th grade, having lots of fun too.
>
> So, if you are going to use PERFORM THRU and GO TO this seems a
> halfway decent way of using them. But I believe I have some choice in
> how I proceed in writing my code, S & P manual may be out of date, but
> I haven't really discussed this much with anyone.
>
> I have been reading much trashing of PERFORM THRU and GO TO this
> morning, and I'm just curious what opinions people have. Obviously, I
> will do things the way my company wants them done, but I will have
> some flexibility in future programs, so I'd like to start thinking
> about it now.
Lucky you!
If your shop standard mandates PERFORM THRU and GO TOs, you'll always have a
job.
| |
| Richard 2007-02-24, 6:55 pm |
| On Feb 25, 7:02 am, "Impy" <Impy.McFergu...@gmail.com> wrote:
> Okay, so I have been doing the Cobol thing for a couple of months now,
> Unisys, DMS2, datasets, batch, BOLTS screens, etc. and quite enjoying
> it. However, it appears our S&P manual states we are to use GO TOs,
Is it dated 1967 ?
> and my fellow Cobol programmers use them, as well as the PERFORM THRU
> statements.
> Okay, they use them pretty cleanly I'd say. PERFORM A100-READ-FILE
> THRU A100-READ-FILE-EXIT, etc. and the GO TOs are only used to loop
> through reads and writes and such, and to go to the exit paragraphs
> upon errors, or maybe in a nested loop to go back to an earlier loop.
>
> It's not exactly spaghetti code (or is it?) , and it's 'the way it's
> done' where I work, so I'm just following orders. This is my first
> programming job, went back to school in my 30's, been toying with
> programming since 7th grade, having lots of fun too.
>
> So, if you are going to use PERFORM THRU and GO TO this seems a
> halfway decent way of using them. But I believe I have some choice in
> how I proceed in writing my code, S & P manual may be out of date, but
> I haven't really discussed this much with anyone.
>
> I have been reading much trashing of PERFORM THRU and GO TO this
> morning, and I'm just curious what opinions people have.
It should be obvious from posts made here over the last couple of
decades. Most have moved on, there isn't much left unsaid on the
subject of GOTO and PERFORM THRU.
I would say, however, that there is nothing wrong at all with a GOTO.
They are clear and precise. When you see one you know exactly what
will happen. The problem lies elsewhere entirely: at the labels that
must exist for them.
> Obviously, I
> will do things the way my company wants them done, but I will have
> some flexibility in future programs, so I'd like to start thinking
> about it now.
| |
|
|
>
> Is it dated 1967 ?
** 2002 ** I think the mandate on the GO TO dates from, lol.
>
> It should be obvious from posts made here over the last couple of
> decades. Most have moved on, there isn't much left unsaid on the
> subject of GOTO and PERFORM THRU.
>
> I would say, however, that there is nothing wrong at all with a GOTO.
> They are clear and precise. When you see one you know exactly what
> will happen. The problem lies elsewhere entirely: at the labels that
> must exist for them.
>
>
> Lucky you!
>
> If your shop standard mandates PERFORM THRU and GO TOs, you'll always have a
> job.
We can't even find people for our existing openings for Cobol
Programmers, and many of the ones there are very near retirement age.
So my job is pretty secure, I think, lol. It's pretty much my job for
as long as I want it, I think I can handle it, still learning after a
couple of months, but I guess I 'look like a Cobol Programmer'.
http://pag.csail.mit.edu/~adonovan/...th=11&year=1997
I'm not sure they mandate the PERFORM THRU, but it is how I'm being
told how to code it. This is a brand spanking new report I'm writing
for an existing subsystem. And the mandate on the GOTO is from about 5
years ago I think.
Yes, I have been reading about this 'style war' for a couple of days
now, and I realize it's an old can of worms best left alone, or a
sleeping dog or something.
I can see a use for GO TOs in Cobol (if you're careful), and if you
keep the paragraphs neat and structured (and never have to change
things), it might not be too bad, but having been doing this for a
WHOLE 2 months, I might not *quite* have the experience or wisdom to
see the bigger picture.
My employer tends to keep their code pretty neat and tidy, but I
think the use of GO TO and PERFORM THRU is more of an inertia thing,
just keep doing it that way cause it ain't broken. But I don't know.
It will be interesting to see how it goes, I like it a lot and can't
wait to go to work in the mornings. Hopefully, it will stay that way.
Thanks all!
| |
|
| In article <1172426711.739083.196360@8g2000cwh.googlegroups.com>,
Impy <Impy.McFerguson@gmail.com> wrote:
>
>
>** 2002 ** I think the mandate on the GO TO dates from, lol.
>
>
>
>
>We can't even find people for our existing openings for Cobol
>Programmers, and many of the ones there are very near retirement age.
>So my job is pretty secure, I think, lol. It's pretty much my job for
>as long as I want it, I think I can handle it, still learning after a
>couple of months, but I guess I 'look like a Cobol Programmer'.
>
>
>http://pag.csail.mit.edu/~adonovan/...th=11&year=1997
>
>I'm not sure they mandate the PERFORM THRU, but it is how I'm being
>told how to code it. This is a brand spanking new report I'm writing
>for an existing subsystem. And the mandate on the GOTO is from about 5
>years ago I think.
>
>Yes, I have been reading about this 'style war' for a couple of days
>now, and I realize it's an old can of worms best left alone, or a
>sleeping dog or something.
>
>I can see a use for GO TOs in Cobol (if you're careful), and if you
>keep the paragraphs neat and structured (and never have to change
>things), it might not be too bad, but having been doing this for a
>WHOLE 2 months, I might not *quite* have the experience or wisdom to
>see the bigger picture.
>
>My employer tends to keep their code pretty neat and tidy, but I
>think the use of GO TO and PERFORM THRU is more of an inertia thing,
>just keep doing it that way cause it ain't broken. But I don't know.
>
>It will be interesting to see how it goes, I like it a lot and can't
>wait to go to work in the mornings. Hopefully, it will stay that way.
>
>Thanks all!
>
>
>
>
| |
| raul@raul.com 2007-02-25, 6:55 pm |
| I have used COBOL for many years, even now sometimes, and I must say I like
it a lot.
I normally use the PERFORM THRU, especially when doing validations. Then, if
the validation fails
you use a GO TO to get to the, say, 1200-VALIDATION-EXIT procedure, which
has an EXIT statement.
There is nothing wrong with it, I'd say.
Raul Ward
| |
|
| On Feb 25, 11:28 pm, r...@raul.com wrote:
> I have used COBOL for many years, even now sometimes, and I must say I like
> it a lot.
>
> I normally use the PERFORM THRU, especially when doing validations. Then, if
> the validation fails
> you use a GO TO to get to the, say, 1200-VALIDATION-EXIT procedure, which
> has an EXIT statement.
>
> There is nothing wrong with it, I'd say.
>
> Raul Ward
I don't think its worth getting too bogged down worrying about using
GO TO's or not, or PERFORM THRU's. What is more relevant is what do
the existing programs do? If they are already written in a particular
style then you would be well advised to adopt that, at least until you
are 100% comfortable with it.
I have personally heard many criticisms of the COBOL GO TO statement
over the past 20 years and I think people forget about the history.
Some of the code was written before we had the constructs that we have
now and the only way to split some conditions up was to use some GO
TO's. But again, if they already exist don't touch them, unless you
are being tasked to do exactly that. I like to use the GO TO command
as long as I'm not going far :-). For example.
MOVE 1 TO WS-SUB.
B100-ADD.
ADD 1 TO WS-SUB.
IF WS-SUB < 100
IF WS-STATUS-ERROR-FLAG(WS-SUB) = 1
PERFORM PROCESS-ERROR
END-IF
GO TO B100-ADD.
Yes, I know, I know. There is at least one easier method just using a
PERFORM VARYING and you don't have to use a GO TO. But please don't
post it. You would be missing the point I'm making. Does it really
matter. As long as its clear and you can see the place its going to as
in this example I feel its as good as anything.
Incidently, am I the last person using SECTIONS. I have heard people
talking about 'falling through' but I don't get this problem. When I
want to exit a section I do just that with the EXIT SECTION statement.
Regards
Razor
| |
| Howard Brazee 2007-02-26, 6:55 pm |
| With this style, I suspect the primary use of GO TO is as a GO TO
THIS-LOOP-EXIT.
You may also have them for program exits.
It is possible that you will see GO TO THIS-LOOP-TOP or GO TO
THIS-LOOP-MIDDLE. If these aren't mandated, you should be able to
avoid writing these.
| |
| Michael Russell 2007-02-27, 6:55 pm |
| Top Post:
Solving problems in code is an opportunity for elegance &
simplicity.
These two constructs are inelegant and show lack of
appreciation of good design.
They're old hat: shabby old hat.
Best avoided unless your job depends on it.
Write code so that some day, perhaps, someone could enjoy
reading it.
Regards
Michael
Impy wrote:
> Okay, so I have been doing the Cobol thing for a couple of months now,
> Unisys, DMS2, datasets, batch, BOLTS screens, etc. and quite enjoying
> it. However, it appears our S&P manual states we are to use GO TOs,
> and my fellow Cobol programmers use them, as well as the PERFORM THRU
> statements.
>
> Okay, they use them pretty cleanly I'd say. PERFORM A100-READ-FILE
> THRU A100-READ-FILE-EXIT, etc. and the GO TOs are only used to loop
> through reads and writes and such, and to go to the exit paragraphs
> upon errors, or maybe in a nested loop to go back to an earlier loop.
>
> It's not exactly spaghetti code (or is it?) , and it's 'the way it's
> done' where I work, so I'm just following orders. This is my first
> programming job, went back to school in my 30's, been toying with
> programming since 7th grade, having lots of fun too.
>
> So, if you are going to use PERFORM THRU and GO TO this seems a
> halfway decent way of using them. But I believe I have some choice in
> how I proceed in writing my code, S & P manual may be out of date, but
> I haven't really discussed this much with anyone.
>
> I have been reading much trashing of PERFORM THRU and GO TO this
> morning, and I'm just curious what opinions people have. Obviously, I
> will do things the way my company wants them done, but I will have
> some flexibility in future programs, so I'd like to start thinking
> about it now.
>
> Thanks
> Impy
>
| |
| Pete Dashwood 2007-02-27, 9:55 pm |
|
"ruddy" <iruddock@blueyonder.co.uk> wrote in message
news:1172482649.993940.291000@v33g2000cwv.googlegroups.com...
> On Feb 25, 11:28 pm, r...@raul.com wrote:
>
>
> I don't think its worth getting too bogged down worrying about using
> GO TO's or not, or PERFORM THRU's. What is more relevant is what do
> the existing programs do? If they are already written in a particular
> style then you would be well advised to adopt that, at least until you
> are 100% comfortable with it.
>
> I have personally heard many criticisms of the COBOL GO TO statement
> over the past 20 years and I think people forget about the history.
> Some of the code was written before we had the constructs that we have
> now and the only way to split some conditions up was to use some GO
> TO's. But again, if they already exist don't touch them, unless you
> are being tasked to do exactly that. I like to use the GO TO command
> as long as I'm not going far :-). For example.
>
> MOVE 1 TO WS-SUB.
> B100-ADD.
> ADD 1 TO WS-SUB.
> IF WS-SUB < 100
> IF WS-STATUS-ERROR-FLAG(WS-SUB) = 1
> PERFORM PROCESS-ERROR
> END-IF
> GO TO B100-ADD.
>
> Yes, I know, I know. There is at least one easier method just using a
> PERFORM VARYING and you don't have to use a GO TO. But please don't
> post it. You would be missing the point I'm making.
I think your point fails to be "made"... :-)
The first status flag in the above will never be tested, the mixing of
scope-delimited COBOL with full-stop-terminated COBOL is ugly and confusing,
and all of this without even looking at whether GO TO is OK or not... :-)
>Does it really
> matter.
It does if someone else has to maintain it. If you are the only person who
will ever use or change it, then it doesn't. (Have you met Tony Dilworth...
?)
>As long as its clear and you can see the place its going to as
> in this example I feel its as good as anything.
>
Well, that's all right then... :-)
(Seriously, there is nothing wrong with GO TO when used carefully and when
the destination is local;;; Richard already commented that the problem is in
the labels and I think he has a point. Having said all of that, I prefer NOT
to use GO TO for my own programs (I'm just not Evangelical about it... :-)))
> Incidently, am I the last person using SECTIONS.
No, you're not. I still use them (have since early 70s, after experimenting
with PERFORM...THROUGH) and find them very useful, even in OO COBOL. Have a
look at some code I posted here a few w s back (something I hardly ever do
because the style wars generated are just tedious...) and feel free to
criticize ... give you a chance to get your own back for my comments
above... :-)
http://groups.google.com/group/comp...q%3Dproductivit
y%26rnum%3D25%26hl%3Den%26#doc_e59987cf1
370a3fa
Pete.
| |
| Michael Mattias 2007-02-28, 7:55 am |
| > I don't think its worth getting too bogged down worrying about using
> GO TO's or not, or PERFORM THRU's.
For sure it ain't worth another 400-post monster thread on the topic.
That's why archives are available.
MCM
| |
| Howard Brazee 2007-02-28, 6:55 pm |
| On Wed, 28 Feb 2007 15:46:07 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>The first status flag in the above will never be tested, the mixing of
>scope-delimited COBOL with full-stop-terminated COBOL is ugly and confusing,
>and all of this without even looking at whether GO TO is OK or not... :-)
I couldn't disagree more.
| |
| Michael Mattias 2007-02-28, 6:55 pm |
| "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:54k8niF20o965U1@mid.individual.net...
> the mixing of scope-delimited COBOL with full-stop-terminated COBOL is
> ugly and confusing..
Amen.
I find the same thing in BASIC.
These mean the same thing...
IF Condition1 THEN
DoSomething1
END IF
(called 'block if')
and
IF Condition1 THEN DoSomething1
(called "single-line if")
But you can mix and match and boy, that IS confusing...
IF Condition1 THEN
IF Condition2 THEN DoSomething2 <<< Executed only when both
Condition1 and Condition2 are true
DoSomething1 <<< Executed whenever
condition1 is true regardless of condition2
END IF
Of course in Real Life the distance between "IF Condition1" and its
companion END IF is many many lines of source code. Darned near impossible
to figure out what the logic flow is in that case.
It gets worse when ( ly) the single-line IF includes an EXIT or GOTO
statement, eg
IF Condition1 THEN
IF Condition2 THEN DoSomething2: EXIT
DoSomething1
END IF
BASIC EXIT is similar to COBOL EXIT "structure type" (e.g. PARAGRAPH,
PERFORM, SECTION) except 'structure type' is optional; when "structure
type" is omitted EXIT exits the current loop structure regardless of its
type (FOR, DO, IF, TRY, FUNCTION, SUB, SELECT or WHILE).
I tell others to use block IF or single-line IF - whatever they are comfy
with - but don't intersperse them like this.
MCM
| |
| Frank Swarbrick 2007-02-28, 6:55 pm |
| Michael Mattias<mmattias@talsystems.com> 02/28/07 10:53 AM >>>
>"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>news:54k8niF20o965U1@mid.individual.net...
>
>Amen.
>
>I find the same thing in BASIC.
>
>These mean the same thing...
>IF Condition1 THEN
> DoSomething1
>END IF
>(called 'block if')
>
>and
>IF Condition1 THEN DoSomething1
>(called "single-line if")
>
>
>But you can mix and match and boy, that IS confusing...
>
>IF Condition1 THEN
> IF Condition2 THEN DoSomething2 <<< Executed only when both
>Condition1 and Condition2 are true
> DoSomething1 <<< Executed whenever
>condition1 is true regardless of condition2
>END IF
Here's something similar in C (and other C-like languages, I assume):
if (condition1)
{
if (condition2)
DoSomething2();
DoSomething1();
}
I personally don't find that hard to read, though I do understand your
point.
>Of course in Real Life the distance between "IF Condition1" and its
>companion END IF is many many lines of source code. Darned near impossible
>to figure out what the logic flow is in that case.
>
>It gets worse when (ly) the single-line IF includes an EXIT or GOTO
>statement, eg
>
>IF Condition1 THEN
> IF Condition2 THEN DoSomething2: EXIT
> DoSomething1
>END IF
>
>BASIC EXIT is similar to COBOL EXIT "structure type" (e.g. PARAGRAPH,
>PERFORM, SECTION) except 'structure type' is optional; when "structure
>type" is omitted EXIT exits the current loop structure regardless of its
>type (FOR, DO, IF, TRY, FUNCTION, SUB, SELECT or WHILE).
Wow, now that one is, umm, interesting. :-)
>I tell others to use block IF or single-line IF - whatever they are comfy
>with - but don't intersperse them like this.
COBOL doesn't really have a 'single line IF' in the same sense as the other
examples. By that I mean you can't have:
if condition1
if condition2 perform DoSomething2
perform DoSomething1
end-if.
(Well, you can have it, but it won't do what you intend! :-)
Anyway....
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
| |
| Richard 2007-02-28, 6:55 pm |
| On Mar 1, 6:53 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
> I find the same thing in BASIC.
>
> These mean the same thing...
> IF Condition1 THEN
> DoSomething1
> END IF
> (called 'block if')
>
> and
> IF Condition1 THEN DoSomething1
> (called "single-line if")
>
> But you can mix and match and boy, that IS confusing...
In Python the scope of a conditional is entirely controlled by the
indenting. The scope ends when you outdent. This means the the
compiler follows the same rules that you do with your eyes.
if ( condition1 ):
if ( condition2 ):
action2only
another actio2
action1
You must ensure that the editor does not use tab characters, or only
uses tabs otherwise it is impossible to get it to work.
In Python you can't write code that looks confusing.
| |
| Michael Mattias 2007-02-28, 6:55 pm |
| "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:54m1j1F21mm38U1@mid.individual.net...
>
> Wow, now that one is, umm, interesting. :-)
Yes, the creators and maintainers of BASIC continue to invent new kinds of
rope with which the careless, lazy or sloppy may hang themselves!
I've always maintained well-written BASIC looks a lot like well-written
COBOL, whereas poorly-written BASIC looks like.. well, poorly-written BASIC.
MCM
| |
| Howard Brazee 2007-02-28, 6:55 pm |
| On 28 Feb 2007 11:42:22 -0800, "Richard" <riplin@Azonic.co.nz> wrote:
>In Python you can't write code that looks confusing.
I very much doubt that.
| |
| Pete Dashwood 2007-02-28, 6:55 pm |
| X-Trace: individual.net X+WVcIpPNHdRun1VRvQs/AzsxgUND7VbUC5HopV4uVIkYz0R9c
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3028
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:163278
"Howard Brazee" <howard@brazee.net> wrote in message
news:d46bu2pmbuh8c7muk07ter4d3o8o0d23bl@
4ax.com...
> On Wed, 28 Feb 2007 15:46:07 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I couldn't disagree more.
About the flag or the style mix :-)?
Pete.
| |
| Pete Dashwood 2007-02-28, 6:55 pm |
|
"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:GkjFh.2556$M65.85@newssvr21.news.prodigy.net...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:54k8niF20o965U1@mid.individual.net...
>
> Amen.
>
> I find the same thing in BASIC.
>
> These mean the same thing...
> IF Condition1 THEN
> DoSomething1
> END IF
> (called 'block if')
>
> and
> IF Condition1 THEN DoSomething1
> (called "single-line if")
>
>
> But you can mix and match and boy, that IS confusing...
>
> IF Condition1 THEN
> IF Condition2 THEN DoSomething2 <<< Executed only when both
> Condition1 and Condition2 are true
> DoSomething1 <<< Executed whenever
> condition1 is true regardless of condition2
> END IF
>
> Of course in Real Life the distance between "IF Condition1" and its
> companion END IF is many many lines of source code. Darned near impossible
> to figure out what the logic flow is in that case.
>
> It gets worse when (ly) the single-line IF includes an EXIT or GOTO
> statement, eg
>
> IF Condition1 THEN
> IF Condition2 THEN DoSomething2: EXIT
> DoSomething1
> END IF
>
> BASIC EXIT is similar to COBOL EXIT "structure type" (e.g. PARAGRAPH,
> PERFORM, SECTION) except 'structure type' is optional; when "structure
> type" is omitted EXIT exits the current loop structure regardless of its
> type (FOR, DO, IF, TRY, FUNCTION, SUB, SELECT or WHILE).
>
> I tell others to use block IF or single-line IF - whatever they are comfy
> with - but don't intersperse them like this.
>
> MCM
>
Yes, I found in C# (as in Java) you can follow an IF with a single statement
or a block. At first I used whatever was most convenient but as I gained
experience I decided, exactly as you did, to try and be consistent.
Obviously, the block structure is more flexible and allows things to be
added easily later, at the cost of typing a couple of braces.
Nowadays, I automatically type a brace on the line following my
condition...(The C# IDE lets me know if I haven't closed it...)
Mixing styles (in any computer programming language) is usually best
avoided.
Pete.
| |
| Pete Dashwood 2007-02-28, 6:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1172691742.535389.36010@z35g2000cwz.googlegroups.com...
> On Mar 1, 6:53 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
>
>
> In Python the scope of a conditional is entirely controlled by the
> indenting. The scope ends when you outdent. This means the the
> compiler follows the same rules that you do with your eyes.
>
> if ( condition1 ):
> if ( condition2 ):
> action2only
> another actio2
> action1
>
> You must ensure that the editor does not use tab characters, or only
> uses tabs otherwise it is impossible to get it to work.
>
> In Python you can't write code that looks confusing.
>
I dunno, maybe it's me, but that example above just looks "unclosed" to my
somewhat jaundiced eye... :-) I'd like to see a SPECIFIC scope delimiter or
something to tell me the first condition's range has ended. (I'm guessing it
is implicit when the next statement is indented to the same level as the
first "if"? What if there is no further statement (as in the example)... we
are just left hanging... :-))
Having said that, the idea of using in/out-denting to define natural scope
is pretty  .
I'd like to find out more about Python but I just haven't got time at the
moment.
While I'd like to believe your final statement, I wouldn't mind betting
there is SOMEONE SOMEWHERE who CAN write code in python that looks
confusing... :-)
Pete.
| |
| Richard 2007-02-28, 9:55 pm |
| On Mar 1, 10:40 am, Howard Brazee <how...@brazee.net> wrote:
> On 28 Feb 2007 11:42:22 -0800, "Richard" <rip...@Azonic.co.nz> wrote:
>
>
> I very much doubt that.
You can write code that is wrong, but as long as you don't have tab
characters in the file (and my editors will expand tabs and will show
any in the file in colour) then what you see is what you get. You
won't get  because the visual structure is not the logic
structure.
| |
| Roger While 2007-03-01, 3:55 am |
|
"Richard" <riplin@Azonic.co.nz> schrieb im Newsbeitrag
news:1172720964.193481.153810@k78g2000cwa.googlegroups.com...
> On Mar 1, 10:40 am, Howard Brazee <how...@brazee.net> wrote:
>
>
> You can write code that is wrong, but as long as you don't have tab
> characters in the file (and my editors will expand tabs and will show
> any in the file in colour) then what you see is what you get. You
> won't get because the visual structure is not the logic
> structure.
Untangling that last sentence would mean -
I WILL get because the visual structure IS the logic structure.
Hmm.
| |
| Howard Brazee 2007-03-01, 6:55 pm |
| On Thu, 1 Mar 2007 12:15:37 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
>About the flag or the style mix :-)?
I like full stop periods within paragraphs - and always use END-IFs
with my IFs.
| |
| Richard 2007-03-01, 6:55 pm |
| On Mar 1, 9:05 pm, "Roger While" <s...@sim-basis.de> wrote:
> "Richard" <rip...@Azonic.co.nz> schrieb im Newsbeitragnews:1172720964.193481.153810@k78g2000cwa.googlegroups.com...
>
>
>
>
>
> Untangling that last sentence would mean -
> I WILL get because the visual structure IS the logic structure.
>
> Hmm.
But that is because I was using english and not Python to express that
idea. Properly parenthesized it is:
You won't get ( because the visual structure is not the logic
structure).
| |
| Pete Dashwood 2007-03-01, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:qjrdu2172daq1ae22ebqnn7r6uiki905g1@
4ax.com...
> On Thu, 1 Mar 2007 12:15:37 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I like full stop periods within paragraphs - and always use END-IFs
> with my IFs.
Fair enough. A personal preference.
As you may have gathered, I disagree. I think periods were a major cause of
error in "old" COBOL and the fewer you have of them, the better. The only
requirement now (in the Procedure Division...) seems to be immediately
preceding a paragraph/section name and I reckon that is great.
Why would I prefer fewer periods (full stops)...?
1. With some of the old impact printers they didn't render properly and were
easily missed. Sure, that is much less of a problem these days when we print
listings with laser printers, but I have lingering suspicions of any program
listing. Fortunately, I never use COBOL listings these days and haven't for
many years... Still, reducing the periods reduces any real or imagined risk
and makes me feel better :-).
2. Using an end-of-statement terminator (full stop) (which is small and
easily missed) rather than a scope delimiter (which is easily visible and
logically sensible) makes cutting and pasting code much more error prone.
3. Using both scope delimiters and full stops just seems ugly and
unnecessary to me.
I think using END-IF is a step in the right direction, but why not take a
few more steps and use ALL of the scope delimiters? Before you know it you
are thinking in logical scope blocks (just as you would in a modern
language), and periods are just an ugly irrelevance in the middle of your
code... :-)
Pete.
| |
|
|
|
|
| Richard 2007-03-02, 3:55 am |
| On Mar 2, 1:33 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Richard" <rip...@Azonic.co.nz> wrote in message
>
> news:1172774822.548078.321990@31g2000cwt.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
>
>
> I'm not convinced that this is "properly parenthesized"... :-) It still
> contains the extraneous NOT which is causing the problem...
The not is not a problem.
> Quick Boolean analysis... (condition IMPLIES state)
>
> (visual structure = logical structure) -> NOT confusing
> NOT (visual structure = logical stucture) -> confusing
>
> A -> B'
> A' -> B
>
> (You won't get ) = B' ...because...(the visual structure is NOT not
> the logic structure). = NOT B' = B
>
> "You won't get , because the visual structure is the logical
> structure." (Simplest possible form)
If you add a comma then you change the parsing.
The thread was about, and examples were given:
"You will get because the visual structure is not the same as
the logical structure".
Python will not do that. The reverse is made by adding one not:
"You will not get ..."
It's english, not a computer language.
> Logically valid alternative, conveying idea of possible risk...
>
> "You won't get (as you would if the visual structure was NOT the
> logical structure) because the visual structure IS the logical structure."
>
> Python has visual structure = logical structure
> therefore...
> Python -> NOT confusing
>
> BTW, I read a couple of articles about Python last night and it looks quite
> exciting. Some American high schools are adopting it because of its
> simplicity and elegance, using it so students can develop useful
> applications for the school and as a "precursor" to learning C++ at
> university.
Why bother going to C++ ? (or C# or Java)
Over the years I have looked at replacing Cobol with Pascal, Modula2,
Ada, C++, Java, etc. None have had sufficient dynamics to replace the
ease with which Cobol modules can be swapped out when using dynamic
loading (call and cancel).
Python works for me. You can drop replacement bits into a running
system.
> I intend to get into it as soon as I have the current project finished.
Good.
| |
| Richard 2007-03-02, 3:55 am |
| On Mar 2, 12:58 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Howard Brazee" <how...@brazee.net> wrote in message
>
> news:qjrdu2172daq1ae22ebqnn7r6uiki905g1@
4ax.com...
>
>
>
>
>
> Fair enough. A personal preference.
>
> As you may have gathered, I disagree. I think periods were a major cause of
> error in "old" COBOL and the fewer you have of them, the better. The only
> requirement now (in the Procedure Division...) seems to be immediately
> preceding a paragraph/section name and I reckon that is great.
>
> Why would I prefer fewer periods (full stops)...?
>
> 1. With some of the old impact printers they didn't render properly and were
> easily missed. Sure, that is much less of a problem these days when we print
> listings with laser printers, but I have lingering suspicions of any program
> listing. Fortunately, I never use COBOL listings these days and haven't for
> many years... Still, reducing the periods reduces any real or imagined risk
> and makes me feel better :-).
Print a program listing ? How 70s. I haven't done that since I got
Wordstar at the end of that decade.
> 2. Using an end-of-statement terminator (full stop) (which is small and
> easily missed) rather than a scope delimiter (which is easily visible and
> logically sensible) makes cutting and pasting code much more error prone.
My editor highlights full stops as red blocks. They don't get missed.
> 3. Using both scope delimiters and full stops just seems ugly and
> unnecessary to me.
>
> I think using END-IF is a step in the right direction, but why not take a
> few more steps and use ALL of the scope delimiters? Before you know it you
> are thinking in logical scope blocks (just as you would in a modern
> language), and periods are just an ugly irrelevance in the middle of your
> code... :-)
>
> Pete.
| |
| Pete Dashwood 2007-03-02, 6:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1172814373.266489.167110@j27g2000cwj.googlegroups.com...
> On Mar 2, 12:58 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> Print a program listing ? How 70s. I haven't done that since I got
> Wordstar at the end of that decade.
>
I agree. Nevertheless, you will find green lineflo in many programming
cubicles around the World, even today. It is being replaced by stacks of A4
or letter laser printed sheets, but many COBOL programmers use printouts to
save referring back ot the Data Division on screen. I think it stems from
not having a decent IDE, historically.
>
> My editor highlights full stops as red blocks. They don't get missed.
>
Well, that would certainly be better. Unfortunately, I know of no way to do
this with a 3270 screen....(even a colour one... you would simply get a tiny
red dot.)
I don't think it is really the size of the dot that offends me; it is just
using a dot when there is a perfectly good scope delimiter.
Obvbiously, it comes down to personal preference, I was just trying to
explain WHY I have the preference I have.
>
>
Are you advocating the mixing of full stops and scope delimiters, Richard?
If so, I'd be interested in hearing your reasons.
Pete.
| |
| Howard Brazee 2007-03-02, 6:55 pm |
| On Fri, 2 Mar 2007 12:58:50 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>As you may have gathered, I disagree. I think periods were a major cause of
>error in "old" COBOL and the fewer you have of them, the better. The only
>requirement now (in the Procedure Division...) seems to be immediately
>preceding a paragraph/section name and I reckon that is great.
I haven't had that experience, except once where a period was in
column 73. That must have been 25 years ago.
>Why would I prefer fewer periods (full stops)...?
>
>1. With some of the old impact printers they didn't render properly and were
>easily missed. Sure, that is much less of a problem these days when we print
>listings with laser printers, but I have lingering suspicions of any program
>listing. Fortunately, I never use COBOL listings these days and haven't for
>many years... Still, reducing the periods reduces any real or imagined risk
>and makes me feel better :-).
The hard part about impact printers was that commas and periods looked
the same. But I also don't use CoBOL listings these days, so there
is no risk.
>2. Using an end-of-statement terminator (full stop) (which is small and
>easily missed) rather than a scope delimiter (which is easily visible and
>logically sensible) makes cutting and pasting code much more error prone.
It's not an either/or choice, but more of a belts and suspenders
choice.
>3. Using both scope delimiters and full stops just seems ugly and
>unnecessary to me.
It's not ugly for me. But even if wearing both belts and suspenders
is not stylish - my pants don't fall down.
>I think using END-IF is a step in the right direction, but why not take a
>few more steps and use ALL of the scope delimiters? Before you know it you
>are thinking in logical scope blocks (just as you would in a modern
>language), and periods are just an ugly irrelevance in the middle of your
>code... :-)
I've thought about that - but haven't gone that far. Some of them
"seem ugly and unnecessary to me".
Does anybody here use every possible explicit scope delimiter all the
time?
| |
| Howard Brazee 2007-03-02, 6:55 pm |
| On Fri, 02 Mar 2007 08:13:31 -0700, Howard Brazee <howard@brazee.net>
wrote:
>Does anybody here use every possible explicit scope delimiter all the
>time?
I suppose one explicit scope delimiter is the parenthesis. I use
this more than necessary for the code - to make sure that my
intentions were absolutely clear.
I rarely use END-READ, although I probably have written 90% of the
END-READ lines in my shop. I did a search through our source code
for END-COMPUTE with zero matches.
| |
| Richard 2007-03-02, 6:55 pm |
| On Mar 3, 4:07 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Richard" <rip...@Azonic.co.nz> wrote in message
>
> news:1172814373.266489.167110@j27g2000cwj.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
>
>
> I agree. Nevertheless, you will find green lineflo in many programming
> cubicles around the World, even today. It is being replaced by stacks of A4
> or letter laser printed sheets, but many COBOL programmers use printouts to
> save referring back ot the Data Division on screen. I think it stems from
> not having a decent IDE, historically.
>
>
>
> Well, that would certainly be better. Unfortunately, I know of no way to do
> this with a 3270 screen....(even a colour one... you would simply get a tiny
> red dot.)
>
> I don't think it is really the size of the dot that offends me; it is just
> using a dot when there is a perfectly good scope delimiter.
>
> Obvbiously, it comes down to personal preference, I was just trying to
> explain WHY I have the preference I have.
>
>
>
>
> Are you advocating the mixing of full stops and scope delimiters, Richard?
> If so, I'd be interested in hearing your reasons.
Not at all, I am entirely indifferent to what others may do with full
stops. I was just pointing out that the claim they are difficult to
see is not necessarily true for everyone, and so that may be a hollow
claim.
My Cobol programs tend to have hundreds of full stops, especially in
data division. Each one is important so I make sure that they are
visible.
I also have to deal with old code written by others from time to time
so I ensure I have the tools to deal with it easily.
What I would like is a compiler that tells me when I have the scope
terminators wrong, probably as an option, so that I don't have to
bother with counting them.. (this relates to visible logic being
actually what you get).
| |
| Pete Dashwood 2007-03-02, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:0gfgu21l03oju3j42p1uonjjfcge9tsloj@
4ax.com...
> On Fri, 2 Mar 2007 12:58:50 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I haven't had that experience, except once where a period was in
> column 73. That must have been 25 years ago.
>
>
> The hard part about impact printers was that commas and periods looked
> the same. But I also don't use CoBOL listings these days, so there
> is no risk.
>
>
> It's not an either/or choice, but more of a belts and suspenders
> choice.
>
>
> It's not ugly for me. But even if wearing both belts and suspenders
> is not stylish - my pants don't fall down.
>
>
> I've thought about that - but haven't gone that far. Some of them
> "seem ugly and unnecessary to me".
>
Fair enough.
A conclusion I'm coming to is that we all use styles that are most
comfortable for us, without necessarily having any really good reason for
doing so.
(We probably think we have good reason or will justify what we do, but in
the final analysis it is just that that's how we do it. I know that is
certainly the case for me. Much of my own coding style is really based
around arguable aesthetics; I may think it is beautiful and elegant but
someone else may not... :-))
Provided what we do is (easily) understandable to others (if we are working
in environments where others must maintain code we wrote), it probably
really doesn't matter much.
> Does anybody here use every possible explicit scope delimiter all the
> time?
Yes, I do.
Ironically, now that I've learned to write COBOL "properly", I'm abandoning
it... :-)
Pete.
| |
| Pete Dashwood 2007-03-02, 6:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:6nlgu2tp0vus89fdo3pl3reimk0ehd3m3a@
4ax.com...
> On Fri, 02 Mar 2007 08:13:31 -0700, Howard Brazee <howard@brazee.net>
> wrote:
>
>
> I suppose one explicit scope delimiter is the parenthesis. I use
> this more than necessary for the code - to make sure that my
> intentions were absolutely clear.
>
> I rarely use END-READ, although I probably have written 90% of the
> END-READ lines in my shop. I did a search through our source code
> for END-COMPUTE with zero matches.
Yes, I forgot about end-compute. I don't use it normally. But I certainly
would, IF I had a multi-line complex compute. As those are best avoided, my
compute statements tend to occupy a single line.
END-READ (and NOT AT END) I use as a matter of course and have for some
years now.
In fairness, I rarely use files that require READing; relational databases
do all of the serious data storage and it would only be a text file that I'd
be likely to READ.
I find it puzzling that INSPECT has no scope delimiter and every so often I
write END-INSPECT and then have the compiler grizzle and throw it out.
All of the others that I can think of, I use and find useful.
Pete.
| |
| Richard 2007-03-02, 6:55 pm |
| On Mar 3, 10:40 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Howard Brazee" <how...@brazee.net> wrote in message
>
> news:6nlgu2tp0vus89fdo3pl3reimk0ehd3m3a@
4ax.com...
>
>
>
>
>
> Yes, I forgot about end-compute. I don't use it normally. But I certainly
> would, IF I had a multi-line complex compute. As those are best avoided, my
> compute statements tend to occupy a single line.
>
> END-READ (and NOT AT END) I use as a matter of course and have for some
> years now.
>
> In fairness, I rarely use files that require READing; relational databases
> do all of the serious data storage and it would only be a text file that I'd
> be likely to READ.
>
> I find it puzzling that INSPECT has no scope delimiter and every so often I
> write END-INSPECT and then have the compiler grizzle and throw it out.
>
> All of the others that I can think of, I use and find useful.
>
> Pete.
Scope delimitres are only required for conditional statements and not
for imperitive ones.
COMPUTE X = Y + 1 is imperitive
COMPUTE X = Y + 1
ON SIZE ERROR
COMPUTE X = -1
..
is conditional. A _single_ END_COMPUTE is required to make it
equivalent to an imperitive statement.
You do not add scope terminators to statements because it is "a multi-
line complex compute", you only do so because it is conditional with
an 'ON SIZE ERROR'.
| |
| Pete Dashwood 2007-03-02, 6:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1172863854.644008.57150@j27g2000cwj.googlegroups.com...
> On Mar 3, 4:07 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> Not at all, I am entirely indifferent to what others may do with full
> stops. I was just pointing out that the claim they are difficult to
> see is not necessarily true for everyone, and so that may be a hollow
> claim.
>
I think that if we are required to justify most of our style choices, the
claims are hollow or can be refuted. :-)
We just THINK it makes sense and so become comfortable with doing it that
way.
> My Cobol programs tend to have hundreds of full stops, especially in
> data division. Each one is important so I make sure that they are
> visible.
>
I was careful to confine my "full stop objection" to the Procedure Division,
which just shows the illogicality of what I said. (If they are hard to see,
they will be just as hard to see in the Data Division...) It is really an
aesthetic thing, although it may be based on distant memories of times when
there was a real risk of them not being printed correctly.
> I also have to deal with old code written by others from time to time
> so I ensure I have the tools to deal with it easily.
>
> What I would like is a compiler that tells me when I have the scope
> terminators wrong, probably as an option, so that I don't have to
> bother with counting them.. (this relates to visible logic being
> actually what you get).
>
I don't think I have ever counted scope delimiters, although I can see that
with nesting it might be a useful check.
I DO take care to ensure that COBOL is indented into matching blocks which
is part of ensuring that visual logic matches actual logic.
If you have one-too-many delimiters the Fujitsu compiler will tell you, but
it is more cavalier about having too few. It only grumbles if the lack of a
delimiter means the code is ambiguous or it can't understand what you are
doing.
Pete.
| |
| Pete Dashwood 2007-03-02, 6:55 pm |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1172872303.445681.99090@p10g2000cwp.googlegroups.com...
> On Mar 3, 10:40 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> Scope delimitres are only required for conditional statements and not
> for imperitive ones.
>
> COMPUTE X = Y + 1 is imperitive
>
> COMPUTE X = Y + 1
> ON SIZE ERROR
> COMPUTE X = -1
> .
>
> is conditional. A _single_ END_COMPUTE is required to make it
> equivalent to an imperitive statement.
>
> You do not add scope terminators to statements because it is "a multi-
> line complex compute", you only do so because it is conditional with
> an 'ON SIZE ERROR'.
>
No, I do whatever I think is necessary. I can add END-COMPUTE whether it is
a conditional or imperative compute. I may do so for readability or to
ensure that the block is clearly defined.
I was aware of the difference between imperative and conditional COMPUTEs
(and other arithmertic statements).
I WOULD add END-COMPUTE to "a multi-line complex compute" whether it was
conditional or imperative.
Pete.
| |
| William M. Klein 2007-03-02, 6:55 pm |
| Pete,
Do you use scope terminators for NON-conditional forms of statements, e.g.
Compute A = B +1
End-Compute
or
Call "ABC"
End-Call
or do you always add the "conditional phrases" or do something else (well other
than not use COBOL <G> ).
This has always been one of those "odd" situations that I have mixed feelings
about, especially when it CAN end up changing logic flow
--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:54rj9eF222pjiU1@mid.individual.net...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:0gfgu21l03oju3j42p1uonjjfcge9tsloj@
4ax.com...
>
> Fair enough.
>
> A conclusion I'm coming to is that we all use styles that are most comfortable
> for us, without necessarily having any really good reason for doing so.
>
> (We probably think we have good reason or will justify what we do, but in the
> final analysis it is just that that's how we do it. I know that is certainly
> the case for me. Much of my own coding style is really based around arguable
> aesthetics; I may think it is beautiful and elegant but someone else may
> not... :-))
>
> Provided what we do is (easily) understandable to others (if we are working in
> environments where others must maintain code we wrote), it probably really
> doesn't matter much.
>
>
> Yes, I do.
>
> Ironically, now that I've learned to write COBOL "properly", I'm abandoning
> it... :-)
>
> Pete.
>
| |
| William M. Klein 2007-03-02, 6:55 pm |
| Richard (I hadn't read your note before responding to Pete's)
You are (of course) correct that scope delimiters are NEVER required for
imperative statements, but there are times when things get confusing
with/without them. For example,
Call "ABC"
On Exception
Display field-1
Not On Exception
Perform XYZ
| |
| James J. Gavan 2007-03-02, 9:55 pm |
| Pete Dashwood wrote:
> "Howard Brazee" <howard@brazee.net> wrote in message
>
>
> Yes, I do.
>
> Ironically, now that I've learned to write COBOL "properly", I'm abandoning
> it... :-)
>
As well as the COMPUTE, I'm willing to bet that you didn't/don't use the
following as regular usage - I NEVER did :-
END-INVOKE
Now if I go back to the original INVOKE syntax, listed in Ray Obin's
1993 M/F paperback :-
---------------------------------------------------------------------
INVOKE object-identifier-3 {identifier-1 }
{a-n-literal-1}
USING { [BY REFERENCE] (identifier-2] } ] ]
{ BY CONTENT {identifier-3 } } ]
[RETURNING identifier-4 ]
[ON EXCEPTION imperative-statement-1]
[NOT ON EXCEPTION imperative-statement-2]
[END-INVOKE]
With reference to the EXCEPTIONS :-
- If the method is not available, imperative statement-1 will be executed
- When the method has completed, imperative statement-2 2ill be executed.
---------------------------------------------------------------------
That's what the sub-committee (OOCTG) dreamed-up before the main J4
Committee got their sticky hands on the topic.
While Ray's book makes several references to CONFORMANCE and checking,
there are no entries for REPOSITORY, which obviously was added by J4
sometime before Fujitsu produced their first OO compiler. REPOSITORY is
only effective in Net Express from Version 4.0 onwards. Given
Conformance and Repository, it's fairly apparent why the 'EXCEPTIONS' do
not form part of the 2002 INVOKE syntax.
As written above, like Richard described for the COMPUTE, include those
conditionals for ON EXCEPTION/NOT ON EXCEPTION then the END-INVOKE made
sense. Above of course is different from the final COBOL 2002 INVOKE
syntax; while the END-INVOKE is now superfluous, you can see the train
of thought where the SCOPE TERMINATOR was retained.
Jimmy
| |
|
| Impy wrote:
>
> I'm not sure they mandate the PERFORM THRU, but it is how I'm being
> told how to code it. This is a brand spanking new report I'm writing
> for an existing subsystem. And the mandate on the GOTO is from about 5
> years ago I think.
Just because you have to use PERFORM THRU doesn't mean you have to use
GO TO to loop through things. You can specify an exit paragraph without
ever explicitly "GOing TO" it. :)
-8<---
move [value] to [calc-key]
fetch [owning] record
if error-num = zeroes
perform myPara1 thru myParaExit
end-if
| |
| Pete Dashwood 2007-03-03, 7:55 am |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:0h2Gh.82505$_X1.72221@fe05.news.easynews.com...
> Pete,
> Do you use scope terminators for NON-conditional forms of statements,
> e.g.
>
> Compute A = B +1
> End-Compute
>
> or
>
> Call "ABC"
> End-Call
>
> or do you always add the "conditional phrases" or do something else (well
> other than not use COBOL <G> ).
>
> This has always been one of those "odd" situations that I have mixed
> feelings about, especially when it CAN end up changing logic flow
>
I thought I had made it clear... sorry.
I would (probably...) NOT write...
Compute A = B +1
End-Compute
.... because it is quite clear without the scope terminator, and, no scope
terminator is required by the language as it is the imperative form. I would
NOT follow it with a full stop (unless one was required because of an
immediately following label, and then I would put the full stop in column 12
on a line by itself.)
I WOULD (possibly...) write...(do not look for significance; it's a coding
format example...)
compute x = (function STORED-CHAR-LENGTH (some-field) + function ANNUITY
(lump-sum)) *
((ABC * 17.985461) / function
INTEGER-OF-DATE(the-cats-birthday)) +
1/(5/3 * 8/5 * XXXX-all) +
XYZ +
ABC +
DEF +
GHI +
JKL * function MAX (val(ALL)) +
MNO * function MIN (Val(ALL))
end-compute
.... even though there is no strict requirement for the scope delimiter.
I WOULD (definitely...) write...
> Call "ABC"
> End-Call
Seems inconsistent, doesn't it...? (Why not do it for compute? I tried to
answer that in my response to Richard.)
So, why a scope terminator with CALL/INVOKE but NOT with COMPUTE?
The reason is that in this case there is a chance that the CALL will have
parameters added to it later, so I consider it needs a "block". In order to
be consistent as far as CALL/INVOKE are concerned, I therefore ALWAYS code
these with provision for a block, thus...
call "ABC"
using XYZ
returning PQR
on exception
perform wailing-and-gnashing-of-teeth
end-call
....or, in imperative form...
call
"ABC"
end-call
BOTTOM LINE:
If the structure is a de facto "block", or could become a block, or looks
like it needs a block, I use the scope delimiters, whether the language
requires them or not.
The tail doesn't wag the dog :-)
Pete.
| |
| Pete Dashwood 2007-03-03, 7:55 am |
|
"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:L13Gh.1197020$5R2.586039@pd7urf3no...
> Pete Dashwood wrote:
> As well as the COMPUTE, I'm willing to bet that you didn't/don't use the
> following as regular usage - I NEVER did :-
>
> END-INVOKE
Sorry Jimmy, you lose...
I ALWAYS write END-INVOKE or END-CALL, (and have done for years now.)
Got into the habit when using CALL in the Microfocus development for the
Channel Tunnel ticketing (TRIBUTE project)(it was that long ago :-))...long
before OO, and also coded the ON EXCEPTION clause because, in those days we
frequently ran out of memory when trying to call dynamic routines.)
It has nothing to do with the electric wet dreams of J4 or MF or any other
"Authority"; it has to do with making my code readable and clear, and
preparing it for possible future expansion.
See my response to Bill.
>
> Now if I go back to the original INVOKE syntax, listed in Ray Obin's 1993
> M/F paperback :-
>
Aw, sorry, my copy seems to be missing... I'm hopeless when it comes to
hanging onto really important documents... :-)
> ---------------------------------------------------------------------
> INVOKE object-identifier-3 {identifier-1 }
> {a-n-literal-1}
> USING { [BY REFERENCE] (identifier-2] } ] ]
> { BY CONTENT {identifier-3 } } ]
> [RETURNING identifier-4 ]
> [ON EXCEPTION imperative-statement-1]
> [NOT ON EXCEPTION imperative-statement-2]
> [END-INVOKE]
>
> With reference to the EXCEPTIONS :-
>
> - If the method is not available, imperative statement-1 will be executed
>
> - When the method has completed, imperative statement-2 2ill be executed.
>
> ---------------------------------------------------------------------
>
> That's what the sub-committee (OOCTG) dreamed-up before the main J4
> Committee got their sticky hands on the topic.
>
> While Ray's book makes several references to CONFORMANCE and checking,
> there are no entries for REPOSITORY, which obviously was added by J4
> sometime before Fujitsu produced their first OO compiler. REPOSITORY is
> only effective in Net Express from Version 4.0 onwards. Given Conformance
> and Repository, it's fairly apparent why the 'EXCEPTIONS' do not form part
> of the 2002 INVOKE syntax.
>
Ok...
> As written above, like Richard described for the COMPUTE, include those
> conditionals for ON EXCEPTION/NOT ON EXCEPTION then the END-INVOKE made
> sense. Above of course is different from the final COBOL 2002 INVOKE
> syntax; while the END-INVOKE is now superfluous, you can see the train of
> thought where the SCOPE TERMINATOR was retained.
>
No, I can't... and I really don't care... :-)
Pete.
| |
| Charles Hottel 2007-03-03, 9:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:54p7lrF21d53dU1@mid.individual.net...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:qjrdu2172daq1ae22ebqnn7r6uiki905g1@
4ax.com...
>
> Fair enough. A personal preference.
>
> As you may have gathered, I disagree. I think periods were a major cause
> of error in "old" COBOL and the fewer you have of them, the better. The
> only requirement now (in the Procedure Division...) seems to be
> immediately preceding a paragraph/section name and I reckon that is great.
>
> Why would I prefer fewer periods (full stops)...?
>
> 1. With some of the old impact printers they didn't render properly and
> were easily missed. Sure, that is much less of a problem these days when
> we print listings with laser printers, but I have lingering suspicions of
> any program listing. Fortunately, I never use COBOL listings these days
> and haven't for many years... Still, reducing the periods reduces any real
> or imagined risk and makes me feel better :-).
>
> 2. Using an end-of-statement terminator (full stop) (which is small and
> easily missed) rather than a scope delimiter (which is easily visible and
> logically sensible) makes cutting and pasting code much more error prone.
>
> 3. Using both scope delimiters and full stops just seems ugly and
> unnecessary to me.
>
> I think using END-IF is a step in the right direction, but why not take a
> few more steps and use ALL of the scope delimiters? Before you know it you
> are thinking in logical scope blocks (just as you would in a modern
> language), and periods are just an ugly irrelevance in the middle of your
> code... :-)
>
> Pete.
>
There are many ways to write a nested IF statement. Here is one style I have
seen (with the ending left unfinished):
IF
stmts
ELSE IF
stmts
ELSE IF
stmts
ELSE IF
stmts
ELSE IF
stmts
How would you choose to end something like this?
1. You could just put a period at the end of the last statement in the last
ELSE IF.
2. You could code END-IF with a period.
3. You could code an END-IF for each IF all on one line, with or without a
period after the last one. The more IFs the more chance of getting it wrong
and the harder it will be to read. Of course the IBM mainframe compiler
shows you a nesting level number to aid in this type of thing.
| |
|
| Charles Hottel wrote:
> There are many ways to write a nested IF statement. Here is one style I have
> seen (with the ending left unfinished):
>
> IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
>
> How would you choose to end something like this?
I would end it with "END-EVALUATE" - because I would convert the
structure to "EVALUATE TRUE", and each of the nested IFs would become
WHENs. :) (Is that cheating?)
> 1. You could just put a period at the end of the last statement in the last
> ELSE IF.
>
> 2. You could code END-IF with a period.
>
> 3. You could code an END-IF for each IF all on one line, with or without a
> period after the last one. The more IFs the more chance of getting it wrong
> and the harder it will be to read. Of course the IBM mainframe compiler
> shows you a nesting level number to aid in this type of thing.
If I wasn't allowed to change the structure, I'd probably go with #2.
It matches the if...elseif...elseif...endif structure of some other
languages. Plus, with them not indented, it would be (to me) the most
obvious ending delimiter to a structure like that.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Pete Dashwood 2007-03-04, 3:55 am |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:i5qGh.6286$PL.2602@newsread4.news.pas.earthlink.net...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:54p7lrF21d53dU1@mid.individual.net...
>
> There are many ways to write a nested IF statement. Here is one style I
> have seen (with the ending left unfinished):
>
> IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
>
> How would you choose to end something like this?
>
> 1. You could just put a period at the end of the last statement in the
> last ELSE IF.
>
> 2. You could code END-IF with a period.
>
> 3. You could code an END-IF for each IF all on one line, with or without a
> period after the last one. The more IFs the more chance of getting it
> wrong and the harder it will be to read. Of course the IBM mainframe
> compiler shows you a nesting level number to aid in this type of thing.
>
>
I simply wouldn't use that construct.
For me that is NOT a "pure" nested IF (and those are the only kind I
use...); it doesn't represent a decision tree with conditions nested in the
TRUE branches. I discussed this elsewhere in CLC fairly recently...(December
20th, 1999...7 years is nothing to an old codger like me :-))
http://groups.google.com/group/comp...330087ea14ea382
The above (Charlie's example, not my nested IF dissertation...) is best
served by an EVALUATE, with each of the ELSE statements being replaced by
WHEN.
Leaving the fine points of how to do stuff aside, and coming back to your
question, this is again a case of letting the format reflect the logic. I
would structure it as
IF
stmts
ELSE IF
stmts
ELSE IF
stmts
ELSE IF
stmts
ELSE IF
stmts
END-IF
END-IF
END-IF
END-IF
END-IF
.... with absolutely no sign of a full stop anywhere in the
neighbourhood...but taking great care to ensure the indentation matched up
correctly and that the count of END-IFs matches the count of IFs (That's a
very good idea I picked up from Richard... :-))
This is a perfect example of what Richard was saying about Python... Things
become clearer when the visual format represents the logical structure.
And I would submit that it bears out my own preference re mixing styles;
adding periods to the above does nothing to clarify it or make it more
readable, in fact, it has exactly the opposite effect...
Pete.
| |
| Pete Dashwood 2007-03-04, 3:55 am |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:WqmdnbQDAZfHr3fYnZ2dnUVZ_tfinZ2d@co
mcast.com...
> Charles Hottel wrote:
>
> I would end it with "END-EVALUATE" - because I would convert the structure
> to "EVALUATE TRUE", and each of the nested IFs would become WHENs. :)
> (Is that cheating?)
>
No, it isn't cheating, it is sound good sense. (I read your post after
posting mine on the same subject...:-))
>
> If I wasn't allowed to change the structure, I'd probably go with #2. It
> matches the if...elseif...elseif...endif structure of some other
> languages. Plus, with them not indented, it would be (to me) the most
> obvious ending delimiter to a structure like that.
>
Not me. I'd rewrite the whole construct to use EVALUATE.
If they kicked up about that or said it was banned by S & P, I'd have a
programmers workshop and get the standards changed. :-)
If it was a really urgent fix I'd ask them to decide whether their
restrictive standard and continuing bad coding practice were more important
than getting it done. I'd demonstrate that it worked perfectly with the
EVALUATE in place (fait accompli is often a powerful persuader... :-)).
If that battle was lost, I'd ask them to get someone else to change it, as I
really feel very strongly about writing crap code.
If they insisted that I do it, and do it the way they wanted, (on the basis
that they are paying me and I have accepted the contract) I'd use option 3
without a period at the end, and I'd add a disclaiming note to the code
stating it was done under extreme duress and denying all responsibility for
it. I'd also immediately terminate the contract on the grounds that I was
completely unsuited for working on their site, and it was therefore in the
interest of all concerned for me to move on.
But if it came to that point, I wouldn't be working there anyway... :-)
Pete.
| |
| Richard 2007-03-04, 3:55 am |
| On Mar 4, 5:25 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Charles Hottel" <chot...@earthlink.net> wrote in message
>
> news:i5qGh.6286$PL.2602@newsread4.news.pas.earthlink.net...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I simply wouldn't use that construct.
>
> For me that is NOT a "pure" nested IF (and those are the only kind I
> use...); it doesn't represent a decision tree with conditions nested in the
> TRUE branches. I discussed this elsewhere in CLC fairly recently...(December
> 20th, 1999...7 years is nothing to an old codger like me :-))
>
> http://groups.google.com/group/comp.../thread/6a7a...
>
> The above (Charlie's example, not my nested IF dissertation...) is best
> served by an EVALUATE, with each of the ELSE statements being replaced by
> WHEN.
>
> Leaving the fine points of how to do stuff aside, and coming back to your
> question, this is again a case of letting the format reflect the logic. I
> would structure it as
>
> IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
> END-IF
> END-IF
> END-IF
> END-IF
> END-IF
>
> ... with absolutely no sign of a full stop anywhere in the
> neighbourhood...but taking great care to ensure the indentation matched up
> correctly and that the count of END-IFs matches the count of IFs (That's a
> very good idea I picked up from Richard... :-))
>
> This is a perfect example of what Richard was saying about Python... Things
> become clearer when the visual format represents the logical structure.
>
> And I would submit that it bears out my own preference re mixing styles;
> adding periods to the above does nothing to clarify it or make it more
> readable, in fact, it has exactly the opposite effect...
Well actually Python does not have a case statement and uses elif as
an else if. The nesting of these does impose a particular indenting,
but it is that of Charles, not that of yours.
if ( a ):
do a bits
elif ( b ):
do b bits
...
Of course you could do:
if ( a ):
do a bits
else:
if ( b ):
do b bits
The lack of a case statement id a philosophic decision - in Python
there should only be one way of doing anything.
I don't particularly like EVALUATE TRUE and would do with a series of
IF .. ELSE IF with all the IFs at the same indent, just like Python
requires with a series of elifs.
| |
|
| In article <i5qGh.6286$PL.2602@newsread4.news.pas.earthlink.net>,
Charles Hottel <chottel@earthlink.net> wrote:
[snip]
>There are many ways to write a nested IF statement. Here is one style I have
>seen (with the ending left unfinished):
>
>IF
> stmts
>ELSE IF
> stmts
>ELSE IF
> stmts
>ELSE IF
> stmts
>ELSE IF
> stmts
>
>How would you choose to end something like this?
I cannot speak for Mr Dashwood, of course... but based on previous
experiences I would, most likely, terminate such a structure in a manner
similar to the one used most frequently at the client's site.
'It might look ugly to *you*, sure, but *we're* used to ugly around here.'
DD
| |
| Pete Dashwood 2007-03-04, 7:55 am |
|
"Richard" <riplin@Azonic.co.nz> wrote in message
news:1172992248.712776.186760@i80g2000cwc.googlegroups.com...
> On Mar 4, 5:25 pm, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> Well actually Python does not have a case statement and uses elif as
> an else if. The nesting of these does impose a particular indenting,
> but it is that of Charles, not that of yours.
>
> if ( a ):
> do a bits
> elif ( b ):
> do b bits
> ...
>
I think that's OK... :-) (I can mentally "translate" elif into "case"...
:-))
> Of course you could do:
>
> if ( a ):
> do a bits
> else:
> if ( b ):
> do b bits
>
Less keen on that. I think the first option works fine for me.
> The lack of a case statement id a philosophic decision - in Python
> there should only be one way of doing anything.
Sounds a bit Nazi :-) (but there is efficiency in Dictatorship...)
>
> I don't particularly like EVALUATE TRUE and would do with a series of
> IF .. ELSE IF with all the IFs at the same indent, just like Python
> requires with a series of elifs.
Fair enough.
>
I don't like EVALUATE TRUE either... much prefer to evaluate on something
that is controlling the logic flow (shades of GO TO...DEPENDING ON :-))
Indentation is definitely a personal preference and I've spent some time
here recently explaining why I indent the way I do. That is not intended to
devalue anyone else's way of doing it; rather, people who haven't yet
decided on the style they will use may find an explanation helpful. I
remember when I started COBOL and how bewildering the various styles I
encountered were. Until confidence is gained, it can be a bit intimidating.
Pete.
| |
| Pete Dashwood 2007-03-04, 7:55 am |
|
<docdwarf@panix.com> wrote in message news:esdtra$fb0$1@reader2.panix.com...
> In article <i5qGh.6286$PL.2602@newsread4.news.pas.earthlink.net>,
> Charles Hottel <chottel@earthlink.net> wrote:
>
> [snip]
>
>
> I cannot speak for Mr Dashwood, of course... but based on previous
> experiences I would, most likely, terminate such a structure in a manner
> similar to the one used most frequently at the client's site.
>
> 'It might look ugly to *you*, sure, but *we're* used to ugly around here.'
>
> DD
>
Yes, we've discussed this one before.
There is a definite case for:
"They are paying me to do what they ask, so I'll do what they ask."
While I accept it is commercially ethical, to me, it smacks of a Nuremburg
defence... Should we follow orders even when we know that the orders are
stupid or at least based on lack of understanding or "We've always done it
that way"?
I think my reservation about this arises when they ask me to do something
which I REALLY wouldn't do. It is one thing being a cyber whore and taking
money for services, but even whores have limits... For me, (and I accept
this isn't true for everybody, and I don't think the people it isn't true
for are "wrong") there is a point where it becomes: "No, sorry, I won't do
that..." or, OK, but if you want me to do that, I charge extra..." :-)
There is middle ground here, where you can make a case and explain why you
object, and suggest an alternative that would be better. As they are
employing you as a "consultant" you have a perfect right to offer them
advice, in fact, it can be argued that you are morally bound to do so. They
are buying your expertise; give them some benefit from it other than just
complying with bad practice.
In the final analysis this will come down to individual personalities,
backgrounds, environments, and attitudes and there isn't necessarily a
"right" or "wrong" approach.
Throughout my programming career (around 25 years of a career that is
currently in its 42nd year) I have always done my best to change minds where
there was a chance of improving things, and simply moved on when there
wasn't. Some sites value this, some sites don't. I think it is not good for
the growth of a contractor to stay too long in one place. It is easy to get
into a comfortable rut and just keep on taking the money... Moving exposes
you to new ideas, new platforms, new ways of doing things and different
attitudes. All of this is good for growth.
These days, I get paid to have opinions and manage others who are grappling
with the things I grappled with years ago (the platforms may be different
but the problems of software development don't change much...). It is fun
and I like it. I enjoy watching them and myself grow, and I hope I never
become Doc's "Corner Office Idiot" :-). Invariably, the teams are sorry to
see me go (although some of the management may breathe a quiet sigh of
relief :-)) and I am sorry to leave. However, it gives me a chance to take
some time off and do some of the back-burner projects I set myself (writing
prose and software for fun and, sometimes, profit... :-)) before I finally
have to go back to work and get a "real" job.
BOTTOM LINE:
Whether you opt to toe the line and take the money, or challenge what you
believe is wrong and (possibly not) take the money, is an individual
decision that will depend on individual factors and circumstances. It can
only be right or wrong for an individual, and not for everyone.
Pete.
| |
| HeyBub 2007-03-04, 7:55 am |
| Charles Hottel wrote:
>
> There are many ways to write a nested IF statement. Here is one style
> I have seen (with the ending left unfinished):
>
> IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
> ELSE IF
> stmts
>
> How would you choose to end something like this?
END-IF(4)?
| |
| Charles Hottel 2007-03-04, 7:55 am |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:WqmdnbQDAZfHr3fYnZ2dnUVZ_tfinZ2d@co
mcast.com...
> Charles Hottel wrote:
>
> I would end it with "END-EVALUATE" - because I would convert the structure
> to "EVALUATE TRUE", and each of the nested IFs would become WHENs. :)
> (Is that cheating?)
<snip>
Unfortunately this kind of rewiriting is considered wasted effort by
management where I work and it is "discouraged".
| |
| Charles Hottel 2007-03-04, 7:55 am |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:54v01nF22mrarU1@mid.individual.net...
>
<snip>
> I simply wouldn't use that construct.
>
> For me that is NOT a "pure" nested IF (and those are the only kind I
> use...); it doesn't represent a decision tree with conditions nested in
> the TRUE branches. I discussed this elsewhere in CLC fairly
> recently...(December 20th, 1999...7 years is nothing to an old codger like
> me :-))
>
> http://groups.google.com/group/comp...330087ea14ea382
>
<snip>
Well I admit I have not seen it used often in COBOL programs, But it is a
style I have seen suggested in several books on programming in C.
| |
| Pete Dashwood 2007-03-04, 6:55 pm |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:p%zGh.9073$tD2.6493@newsread1.news.pas.earthlink.net...
>
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:WqmdnbQDAZfHr3fYnZ2dnUVZ_tfinZ2d@co
mcast.com...
>
> <snip>
>
> Unfortunately this kind of rewiriting is considered wasted effort by
> management where I work and it is "discouraged".
>
Maybe time to educate the Management... :-)
It is no more effort to replace the structure with EVALUATE than it is to
put full stops and scope delimiters into it.
It WOULD be wasted effort if the thing didn't need maintaining, but it does.
Perhaps the Management need to understand that "discouraging" better
practices does not improve morale (read "productivity") and, in very
practical terms, actually means the cost of maintaining code is increased.
Management who stamp on enthusiasm and encourage bad practice actually
deserve everything they get...
Pete.
| |
| Pete Dashwood 2007-03-04, 6:55 pm |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:R2AGh.9074$tD2.4723@newsread1.news.pas.earthlink.net...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:54v01nF22mrarU1@mid.individual.net...
>
> <snip>
>
>
> <snip>
>
> Well I admit I have not seen it used often in COBOL programs, But it is a
> style I have seen suggested in several books on programming in C.
>
So if the words for "out", "outer or otherwise", "by means of", "with",
"since", "after or in the style of" and "up to" (aus, ausser, bei, mit,
nach, seit, von, and zu) all take the Dative case in German, does that mean
that they should in English :-)?
Learning other languages is, on the whole, a good thing, but let's not lose
sight of the case in point... COBOL.
Sometimes (until much later when the finer points are grasped) something can
seem like something we already know and understand, when in fact, it isn't.
It isn't ITSA, it's ITSLIKE... similar, but not the same, and very often the
subtle differences are VERY important. C has such a construct probably
because many people coming to C will expect it, and CASE and SWITCH type
constructs can be intimidating to people who haven't encountered them
before; Python has it, as Richard described, because there is no other
alternative. None of these are good reasons for using it in COBOL which DOES
have much better alternatives.
The person who writes a book on C might write a quite different book if
describing COBOL. :-)
Pete.
| |
| Rick Smith 2007-03-04, 6:55 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5504b1F2358jsU1@mid.individual.net...
[snip]
> The person who writes a book on C might write a quite different book if
> describing COBOL. :-)
"How to Convert COBOL to C" by Ob Fuscater?
| |
|
| In article <54vn4eF22qc81U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:esdtra$fb0$1@reader2.panix.com...
>
>Yes, we've discussed this one before.
Yet Mr Hottel sees a need to revisit it... perhaps something new may be
learnt from this revisiting.
>
>There is a definite case for:
>
>"They are paying me to do what they ask, so I'll do what they ask."
That is the basis of contractural fulfillment, certainly.
>
>While I accept it is commercially ethical, to me, it smacks of a Nuremburg
>defence...
Mr Dashwood, if the arguments you bring forward for structuring a slew of
IF... ELSE code are so insubstantial that you need to base them in the
ash-beds of the Auschwitcz crematoria then perhaps you might do well to
revisit them.
In accordance with Godwin's Law
http://catb.org/esr/jargon/html/G/Godwins-Law.html) this thread may be
considered ended... but it might be interesting to see where Mr Dashwood's
logic takes it.
>Should we follow orders even when we know that the orders are
>stupid or at least based on lack of understanding or "We've always done it
>that way"?
No, Mr Dashwood, code should be structured in fashions which are most
readily apprensible by majority of the maintaining-base of pgrogrammers,
the 'shop standard', as it were. No 'Nicht Schuldig!', no 'Befehl is
Befehl'... you take the King's penny, Mr Dashwood, and you write to the
King's specs. Don't like it? Don't take the job... but if you *do* take
the job and don't write to the specs then don't be surprised if your work
doesn't pass Prod review.
[snip]
>There is middle ground here, where you can make a case and explain why you
>object, and suggest an alternative that would be better. As they are
>employing you as a "consultant" you have a perfect right to offer them
>advic | | |