Re: Cobol work?


"Joe Zitzelberger" <joe_zitzelberger@xxxxxxxxxx> wrote in message
news:joe_zitzelberger-928944.08564301112005@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> In article <11mblqoe7apn380@xxxxxxxxxxxxxxxxxx>,
> "Rick Smith" <ricksmith@xxxxxxx> wrote:
>
> > "Joe Zitzelberger" <joe_zitzelberger@xxxxxxxxxx> wrote in message
> > news:joe_zitzelberger-58F137.22362830102005@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> > [snip]
> > > Cobol, alone among languages, inverts equality tests in truly weird
> > > ways. Consider the common Cobol-only idiom:
> > >
> > > If a is equal to b
> > > continue
> > > else
> > > --do a not equal to b logic--
> > > end-if
> > >
> > > This is a code style that only a Cobol programmer could love...and it
> > > easily qualifies for the "obfuscated" label compared to the simple,
> > > clear, idiom used in every other programming language known to human
> > > kind.
> >
> > It is most definitely not a "Cobol-only idiom": It is sometimes
> > found in C programs. (Especially those I have written!)
> >
> > Since I am, admittedly, biased. Here is what Steve McConnell,
> > "Code Complete," 1993, pp 312-314, has to say.
> >
> > Follow these guidelines when writing _if_ statements.
> >
> > Write the nominal path through the code first; then
> > write the exceptions. Write your code so that the
> > normal path through the code is clear. Make sure
> > that the exceptions do not obscure the normal path
> > of execution. This is important for both readability
> > and performance. ...
> >
> > Put the normal case after the _if_ rather than after the
> > _else_. Put the case you normally expect to process
> > first. This is in line with the general principle of putting
> > code that results from a decision as close as possible
> > to the decision.
> >
> > Clearly, if the "nominal path" or "normal case" is to do
> > nothing, then either CONTINUE or a null statement should
> > follow the _if_ and the exception should follow the _else_.
> >
> > McConnell then continues.
> >
> > Follow the _if_ with a meaningful statement. Sometimes
> > you see code like the next example, in which the _if_
> > clause is null.
> >
> > C Example of a Null _if_ Clause
> > if ( SomeTest )
> > ;
> > else
> > {
> > /* do something */
> > ...
> > }
> >
> > Most experienced programmers would avoid code like
> > this if only to avoid the work of coding the extra null line
> > and the _else_ line. It looks silly and is easily improved
> > by negating the predicate in the _if_ statement, moving
> > the code from the _else_ clause to the _if_ clause, and
> > eliminating the _else_ clause.
> >
> > H'm, "[m]ost experienced programmers would avoid" implies
> > 'some experienced programmers would not avoid' (ignoring
> > the inexperienced who may not recognize what "looks silly").
> > These "some" then are the exceptions, or might I suggest
> > exceptional programmers, for whom clarity is more important
> > than avoiding "the work of coding" or what "looks silly". <g>
> >
> > Code written "so that the normal path through the code is
> > clear" and "that the exceptions do not obscure the normal
> > path of execution" hardly "qualifies for the 'obfuscated' label".
>
> Everything McConnell wrote in the first part of your quote assumed you
> had two actual paths. You even quote the part where he goes on to say
> that coding two cases when you have only one path is "silly" and "easily
> improved upon".

Well, not quite. In the first part he seems to be making
an assumption that the normal flow will contain no null
statements and is saying to place the normal case
immediately after the _if_; then, if there are exceptions,
place those in the _else_. This is opposed to placing
exceptions after the _if_ and the normal case in the _else.
The instructions are to prevent "haphazard" placement.
This seems to be for the purpose of nested _if_ statements.
[There were examples in the book I did not post.]

In the second part, he says that null statements, following
the _if_ "look silly"; but, if one begins with the assumption
that normal flow will contain no null statements, then, yes,
they may "look silly" because he is not used to them.
However, saying that such statements "look silly" is mere
opinion that may be ignored by those who see things
differently.

[John T. Molloy, "Dress for Success," 1975, expressed
bewilderment that older Jewish males reacted negatively
to those wearing brown shirts.] If McConnell reacts
negatively to null statements following an _if_ and does
so without a better reason than "looks silly", I believe I
can take the position that he doesn't understand what I do.



.

Relevant Pages

  • Re: Cobol work?
    ... Consider the common Cobol-only idiom: ... normal path through the code is clear. ... that the exceptions do not obscure the normal path ... Most experienced programmers would avoid code like ...
    (comp.lang.cobol)
  • Re: Cobol work?
    ... >> This is a code style that only a Cobol programmer could love...and it ... > normal path through the code is clear. ... > that the exceptions do not obscure the normal path ... > 'some experienced programmers would not avoid' (ignoring ...
    (comp.lang.cobol)
  • Re: ALTER design (Was: Code problems with Perform Thru Exit causes fall through)
    ... Perhaps with such weaknesses as maintenance programmers, ... but those rules, over time, may come to have exceptions. ... if not general-exclusionary-rule ... exclusionary rule is present, ...
    (comp.lang.cobol)
  • Re: help this confused C++ newbie(long post!!)
    ... overloading, then move on to templates, then on to exceptions, and so on. ... Second Edition" by Scott Meyers ... Java programmers who migrate to C++... ...
    (comp.lang.cpp)