It can be incredibly painful to make changes to an existing program that has the markings of spaghetti code . And isn't it positively terrifying to make those changes when you don't have a regression test for the program that you can run afterward to ensure that no bugs were inadvertently introduced? Yet that is what we are often called upon to do. When faced with this situation, the smart thing to do is to make the smallest, most isolated change possible, thereby minimizing the ripple effect. Suppose the code you have to modify looks like this: PROCEDURE someone_elses_mess /* || Author: Long-Gone Consultant || Maintained by: Terrified Employee */ IS BEGIN ... lots and lots of convoluted code FOR index IN 1 .. my_collection.COUNT LOOP ... hard-to-understand logic here ... more of the same here END LOOP; END; and you need to add some code between "hard-to-understand logic here" and "more of the same here." If a ce...
For the last twenty years, I have managed to transform an obsession with PL/SQL into a paying job. How cool is that?