0

I've got a very ugly old program to try to organize/prettify. A few thousand lines, a few dozen labels and about 100 goto's. The goto's are about half forward and half backward. They overlap every which way, and there are even some computed goto's and some case statements that spray goto's willy-nilly out of several of their cases. The only bad things that I can say the program does not do is to branch into thens, elses or cases. It uses conditional branches backwards instead of loops, but many of these are within cases statements.

I recall that it was proved maybe 40 or 50 years ago that goto's are not needed if one has loops and if-then-else (not to mention cases). The question is: are there any manageable algorithms or sets of rules to follow, by hand or by computer, to do what the proof proved possible, i.e. translate spaghetti to reasonably readable code with most of the goto's gone?

Lucas Membrane
  • 359
  • 2
  • 7
  • For a few thousand lines, I suspect a hand-crafted refactor would be preferable to trying to source, understand & implement an algorithmic one. Make sure you've got a way of pushing through plenty of test cases into your old and new and run them all every time you change something. – LoztInSpace Feb 03 '16 at 02:40
  • The program controls flow through a UI, so not easy to test. The hand-crafted refactor is stalled because of the difficulty of splitting out subroutines. The parts of the program that might be candidates for subroutines do not have single exit points. They branch back to different points in the maze with goto's. Any way to make sense of such things? – Lucas Membrane Feb 03 '16 at 15:34

0 Answers0