3 ms·
> The spaghetti code in COBOL comes from the very tight coupling between concerns I thought the spaghetti code in COBOL came from liberal use of GOTOs (e.g. fo
by tablespoon 4y ago
> The spaghetti code in COBOL comes from the very tight coupling between concerns
I thought the spaghetti code in COBOL came from liberal use of GOTOs (e.g. following the execution path of the code is like following the path of a single spaghetti noodle in a plate of spaghetti).
- ok123456 4y agoThere's architectural spaghetti and there are lower levels of spaghetti. COBOL introduced alternatives to unconditional jumps in the 60s. You can convert unconditional jumps to different control flow structures through static analysis. Plusfort does this for FORTRAN pretty well. I'm sure there's an equivalent tool for COBOL somewhere. The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor.
- tablespoon 4y ago> There's architectural spaghetti and there are lower levels of spaghetti.... > The problem isn't merely converting goto to PERFORM-TIMES. It's that deep in that loop you're also doing raw database operations, writing stuff to a IBM 3270 terminal, and triggering a batch job to the program monitor. I'm not saying that's not a problem, just that it feels like it could be an anachronism to use "spaghetti code" to refer to that in the context of a COBOL program.