Yet another post debating some of the finer points of application development using CA 2E (Synon).
Over the years apart from justifying my use of 4GL's and model based development tools for rapid development of applications (CA 2E and CA Plex) to the non believers. Oh the arguements that this has caused have been blogged before. See my series on the 3GL v 4GL debate.
The biggest single point of contention from within the 2e community itself is relating to the correct usage and trust factor of the simply named field, "PGM.*Return Code". It may as well have been named Devil's spawn with the amount of hot air I have seen it generate.
For those that don't know, the return code is a floating variable within a program that indicates the current state of the program at the time it is queried? Roughly speaking
When programming a RTVOBJ as a full record fetch type function or as a check existence style function the developer generally has two options. They can either use the return code that is set implicitily by 2e (this can be overrideen by the developer) or declare an explicit field like Record Found Y/N and pass back a value indicating success or otherwise depending if the record was found.
Below I indicate the Pro's and Con's as I see them.
PGM.*Return Code Method
Pro's
A return code is the default way to test for success or otherwise when calling a program.
Requires no additional developer intervention as nearly all the 2e function types automatically set the return code to the appropriate value.
Con's
A Return code is a global variable within the function and is only as accurate as the last line of code that set it. If additional code is added between the called program and the testing point then the original context of checking the return code is broken. Therefore developer beware.
Explicit Field Method
Pro's
Means you can save the value in a LCL field.
If other code is inserted into the action diagram. As long as the value is not overridden you can check this value later in the action diagram or pass the value into another function.
Con's
Adds extra work to default functions that previously required no extra coding. i.e. a record existence check.
If you have two or more calls the original call may need to be stored. If this is required then the flag can be set on by querying the return code anyhow.
This approach doesn’t work for execute messages or user programs which would generally use a return code so the practice doesn’t fit all scenarios.
But what do i think?
Personally. I always preach the KISS principle and to use the tools as they were designed.
Over the years apart from justifying my use of 4GL's and model based development tools for rapid development of applications (CA 2E and CA Plex) to the non believers. Oh the arguements that this has caused have been blogged before. See my series on the 3GL v 4GL debate.
The biggest single point of contention from within the 2e community itself is relating to the correct usage and trust factor of the simply named field, "PGM.*Return Code". It may as well have been named Devil's spawn with the amount of hot air I have seen it generate.
For those that don't know, the return code is a floating variable within a program that indicates the current state of the program at the time it is queried? Roughly speaking
When programming a RTVOBJ as a full record fetch type function or as a check existence style function the developer generally has two options. They can either use the return code that is set implicitily by 2e (this can be overrideen by the developer) or declare an explicit field like Record Found Y/N and pass back a value indicating success or otherwise depending if the record was found.
Below I indicate the Pro's and Con's as I see them.
PGM.*Return Code Method
Pro's
A return code is the default way to test for success or otherwise when calling a program.
Requires no additional developer intervention as nearly all the 2e function types automatically set the return code to the appropriate value.
Con's
A Return code is a global variable within the function and is only as accurate as the last line of code that set it. If additional code is added between the called program and the testing point then the original context of checking the return code is broken. Therefore developer beware.
Explicit Field Method
Pro's
Means you can save the value in a LCL field.
If other code is inserted into the action diagram. As long as the value is not overridden you can check this value later in the action diagram or pass the value into another function.
Con's
Adds extra work to default functions that previously required no extra coding. i.e. a record existence check.
If you have two or more calls the original call may need to be stored. If this is required then the flag can be set on by querying the return code anyhow.
This approach doesn’t work for execute messages or user programs which would generally use a return code so the practice doesn’t fit all scenarios.
But what do i think?
Personally. I always preach the KISS principle and to use the tools as they were designed.
Therefore, you will see me using the return code out of choice, but I would as always, follow any incumbent standards even if they are wrong but I would definately have a go at explaining why they are wrong.......
Thanks for reading.
Lee.
Thanks for reading.
Lee.
The issue I have with "KISS" here is the scope of "simple". Your definition says to me "simple for the original programmer." If all subsequent programmers are smart they will not be caught out by the cons, but are you happy to make that assumption? Bear in mind that the cons of the return code method risk your software's integrity. For the sake of adding some "simple" extra code, you can protect against this potentially harmful issue.
ReplyDeleteMy definition of "simple" is "simple to keep it working."