3 ms·
Fortran77 though. pretty limited set of organizational tools to work with there. Procs and Modules is it, I think (though I'm no expert). Many of the patterns w
by metaphorm 12y ago
Fortran77 though. pretty limited set of organizational tools to work with there. Procs and Modules is it, I think (though I'm no expert). Many of the patterns we're used to using for code organization just wouldn't be available.
So how you would deal with a really big if statement without having more sophisticated tools? The business logic must have had a very large number of conditional branches. Even if you encapsulate the instructions of each branch in their own proc, it still doesn't change the fact that you're going to have a large number of conditions.
This isn't particularly a solved problem even in modern languages. We can use all kinds of layers of abstraction to make individual units of code smaller, but it's sort of an illusion. Splatting your business logic across a dozen or more files/modules/classes whatever might make it easier to look at in a text editor but it doesn't make it easier to develop or test. If you've got complex business logic you're going to have a complex program.
- walshemj 12y agothe system was broken down into a lot of sub processes from memory the 1400 long branch if was just a branching if then else statement - most weren't as bad. A core part of the documentation was large number of A1 sheets which covered an entre wall of our office ;-) The core of the system working out what do to with all the log records was a collection of Pl/1G. We did have to build a lot of extra stuff you get for free nowadays we had a custom build system that you could use to build any part or the whole system written in primes JCL.