| SQR Program Complexity | KEVIN RESCHENBERG
11-29-2006 |
In last week's post on
frequently asked SQR questions,
I said that some of the solutions posted online tend to be
complex or convoluted. There also seem to be several ways
of solving each problem, adding to the confusion. And programs
written by different developers may be formatted very differently.
As a result, SQR programs can seem nearly impossible to read and maintain.
I think that there are a number of reasons for this. Here are a few
of these reasons and some suggestions on what we can do about the
problem.
"Families" of statement types
First, there is the issue that SQR seems to contain two different "families"
of statements: The COBOL-like ones (MOVE, DISPLAY, ADD, etc.) and the
Basic-like ones (LET, SHOW, and the functions). These are freely mixed
in many SQR programs, adding to the confusion. Pick one style. In my
opinion, there is simply no contest. The second group (LET, SHOW, and
functions) is by far the most flexible and easiest to use, and is closer
to the style used by more modern languages. There are better alternatives
to all of the following, so if you want to go with my suggestion, just
stop using these in your original programs:
MOVE ADD MULTIPLY EXTRACT CONCAT
DISPLAY SUBTRACT DIVIDE FIND
These statements offer
no advantages. However, if you are making small changes to a program that
already uses them, you should definitely follow that style.
Code alignment
Aligning code in some sensible way is probably the single most important
thing we can do to make our SQR programs readable and maintainable.
I gave some suggestions on code formatting
here. There is one
particular case I want to mention today. Some people believe that all
SQL, plus the BEGIN-SELECT and END-SELECT statement keywords, must be
aligned in column 1. This is not true. The only thing that must
be in column 1 is a field name in a SELECT. All other code,
including the FROM part of the SELECT, can (and should) be indented.
And those line continuation characters (-)? You don't need them.
Functions
SQR is not, by any measure, a modern object-oriented language containing
a rich framework. OK, but it does provide some useful functions, so we
should use what is available. Now that we have decided to use LET instead
of MOVE, we can make full use of these functions. But there is one little
quirk with the documentation: All of the functions are documented under
LET. I suspect that this tends to "hide" them in the documentation, making
them less prominent than some of the alternatives. For example, we have
the EXTRACT statement, which I'd consider to be one of the older-style
statements that we can ignore. This is documented in its own section, just like
other statements. But the alternative, the SUBSTR function, doesn't have
its own section. It is found under LET. Just to make it even more fun,
the offsets used by EXTRACT and SUBSTR() are incompatible (0-based vs. 1-based).
The same is true of FIND and its alternative, INSTR().
The older-style statements can't use functions, so I sort
of understand why they are documented under LET. (But IF, for example,
can use them.) In any case, I'd suggest reviewing the list of functions.
There are many useful ones that can make your programs easier to write
and maintain.
Some of these issues seem to contribute to SQR's reputation of being
difficult to use. It doesn't have to be.
|
