Do me a favor, would you? Have a quick look at this code and tell me what you think it does...
...
I'm pretty confident that you'll find the second version a lot easier to understand, because it breaks up all those blocks of code into procedures with descriptive names.
But the real beauty of this procedure is a construct Mike Hanson recently showed me, and which I've christened the Hanson Loop:
Code Block |
---|
Note |
While this code does compile, and does use a real dictionary, I make no claims as to whether it works. Certainly it is incomplete, because I haven't yet written the final local procedure. In any case the purpose is not to register students for courses taught by teachers they avoid but to demonstrate how complicated code can be improved. |
There are a couple of things you may find unfamiliar about this code. One is the use of a local map and local procedures. Just as you can (and almost always do) have a map in a program module, you can have maps within modules and within procedures.
Also each procedure is quite short because short blocks of code are generally easier to understand than long blocks of code.
The Hanson Loop
But the real beauty of this procedure is a construct Mike Hanson recently showed me, and which I've christened the Hanson Loop:
Code Block |
---|
StepNumber = 0
Result = Level:Benign
Loop while Result = Level:Benign
StepNumber += 1
execute StepNumber
Result = GetStudentRecord()
Result = BuildListsOfCoursesTakenAndNotTaken()
Result = BuildListOfTeachers()
Result = CountCoursesTaughtToStudent()
Result = SortTeacherListByCountOfCoursesTaughtToStudent()
Result = NarrowTeacherListToFiveMostAvoided()
Result = NarrowCourseNotTakenListToThoseTaughtByFiveMostAvoidedTeachers()
Result = RegisterStudentForRandomlyChosenCourse()
break
end
end
do CloseFiles
Return result |
The Hanson Loop is a while loop - it keeps executing as long as the Result variable is equal to Level:Benign. You could write a siilar similar loop testing for Result = True, but I think there are some important benefits to using the Clarion return levels, which I'll get to in a moment.
...
The beauty of the Hanson Loop is it provides a clear overview of the code being executed by the main procedure, while allowing for clean and efficient error handling. At any time in the sequence of procedure calls a non-benign result will terminate the loop. And this is where the Clarion error levels come inDo you need to wrap this code in a transaction? It's as easy as doing a logout before the loop, and either a commit or a rollback depending on the value of Result.
Now, about those Clarion error levels.
The Clarion error levels
I will admit that it It has taken me years, almost nearly two decades really, to adopt Clarion error levels in my own coding.
I'm still doing so a bit grudginglyalmost completely convinced.
The Clarion help has this to say about error levels, in the context of the ABC ErrorManager object:
Panel | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Six Levels of Treatment By default, the error manager recognizes six different levels of error severity. The default actions for these levels range from no action for benign errors to halting the program for fatal errors. The error manager also supports the intermediate actions of simply notifying the user, or of notifying the user and letting the user decide whether to continue or abort. Customizable Treatments These various levels of treatment are implemented with virtual methods so they are easy to customize. The error manager calls a different virtual method for each severity level, so you can override the default error actions with your own application specific error actions. See the various Take methods for examples. The recognized severity EQUATEs are declared in EQUATES.CLW. These severity levels and their default actions are:
You may define your own additional severity levels and their associated actions. |
These values specifically indicate what actions the ErrorManager may take. But there aren't quite as many of them as there may seem to be at first. Level:User appears nowhere in the ABC class library or the templates, other than as a definition. Level:Program is the same as Level:Fatal, and Level:Fatal means exit the program, so it's not something you're likely to use that often.. So that leaves Benign, Notify, and Cancel.
Over the years I've written may procedures and methods that returned a true/false value, and in those circumstances the Clarion error levels seemed overkill. Of the three really usable levels I seem to only need Benign and Notify, to signify True and False
...
You may define your own additional severity levels and their associated actions. |
These values specifically indicate actions the ErrorManager may take. But there aren't quite as many of them as there may seem to be at first. Level:User appears nowhere in the ABC class library or the templates, other than as a definition. Level:Program is the same as Level:Fatal, and Level:Fatal means exit the program, so it's not something you're likely to use. So that leaves Benign, Notify, and Cancel.
Over the years I've written may procedures and methods that returned a true/false value, and in those circumstances the Clarion error levels seemed overkill. Of the three really usable levels I seem to only need Benign and Notify, to signify True and False. So why not just use True and False?
In part I've adopted the Clarion error levels to be more in sync with the ABC classes, and in part because using levels leaves open the possibility of indicating different levels of success or failure, even if it's not a situation I come across often. But as soon as I do have one of those situations I suddenly become inconsistent, returning True/False in most of my code and three or more values in other code.
As you can see in the example I'm even using Level:Benign when there is only one potential return value, although I've mainly done that to make the code line up neatly and not because I suspect I will need a different value at some point. I could just as easily not assign a value to ReturnValue in any of the lines in the Execute statement - the loop will continue as before and will always move beyond those lines where ReturnValue is never assigned.
Summary
As I said you can always adapt the Hanson Loop to work with True/False values. That's not so important; what does matter is the Execute nested inside the Loop, and the use of local procedures to break up long blocks of code.
If you have long blocks of code that are difficult to understand, I highly recommend the Hanson Loop. Be descriptive in your procedure names, keep your procedures short, and your code will become easier to read and easier to maintain.