Re: Cobol work?


"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".



.

Relevant Pages

  • Re: Cobol work?
    ... Here is what Steve McConnell, ... >> normal path through the code is clear. ... >> that the exceptions do not obscure the normal path ... >> exceptional programmers, for whom clarity is more important ...
    (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)
Loading