November 29, 2006

SQR Program Complexity

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.

Until next time...