Ah, yes, Standards... I'm afraid the original developers of our system didn't have too many of those. Especially relating to INCLUDEs. I've spent the last 28 years developing and refining standards for our system. They're still not perfect and I break them from time to time, but that's extremely rare and only to solve a problem that could not be solved (easily) by sticking with the standards.
I have developed a migration utility that migrates all the components that make up the changes made to the system for a work request. I must admit, I hadn't thought of scanning the items for INCLUDEs and then finding all the programs using it and recompiling them. Thanks for the idea, I'll get right on it! :)
I'm a great believer in modularity, of divvying up a problem into smaller steps, thus I have created a lot of subroutines that do the hard work. The main program basically coordinates these subs. This makes debugging easier and any changes flow right through the system to all the other programs only requiring the sub to be recompiled. Much neater, quicker and safer.
There's one caveat though with external subroutines: The parameters are passed by reference and not by value, thus any changes made to the parameter variables are passed back to the calling program. I overcame this by naming the parameters in the subroutine header with the prefix IN. and OUT. to ensure unique names and also to indicate the direction of data flow to the sub (I also ensure all inflowing data is shown first and all outflowing data is shown last in the parameter list).
------------------------------
Walter Kiess
SA Police Super
------------------------------
Original Message:
Sent: 06-02-2021 12:44
From: Michael Archuleta
Subject: Debugging (in D3)
- In our programming standards we maintain a list of files which contain programs. When an "include" is changed, our compilation process scans each of these files with a FIND for the include and then re-compiles each. Nothing manual – it is all automatic.
- You make a good argument for when not to use INCLUDE. Again, our standard is to only use INCLUDEs for variable definitions (like EQUATEs). Further, our INCLUDEs are one-liners sometimes with lots of semi-colons. This standard has served us well for 30+ years.
- Personally, I feel that code/logic should be in external subroutines and not embedded within INCLUDEs. You can take better advantage of runtime errors this way as well as logging your own calls to these subroutines.
------------------------------
Michael Archuleta
President
ArcSys Inc
Original Message:
Sent: 06-01-2021 19:19
From: Walter Kiess
Subject: Debugging (in D3)
I'm just thinking out loud here...
I personally detest INCLUDEs. Why? Well, for 3 very important reasons:
- If a change is made to the INCLUDEd item, all programs using it must be recompiled. One or more main programs could be missed, thus still using the old code.
- When an error occurs inside an INCLUDEd item, only the line number of the INCLUDE is shown, not the line number inside the INCLUDE itself, thus making debugging an INCLUDE more difficult, nigh impossible depending on its size and complexity.
- INCLUDEs do not isolate the code from the calling/using program, thus accidental (or on purpose) reuse of variables can be a danger, causing unexpected behaviour of the main program.
So here's the question: Is there a way for D3 to show the line number in the INCLUDE where the error occurred? Would this be an enhancement request? Would it even be possible?
If not, how do people go about debugging an INCLUDE? Short of physically embedding the INCLUDE code in the program (temporarily), I can't think of any other way to do it.
------------------------------
Walter Kiess
SA Police Super
------------------------------