Just another Perl shrine | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
So, here I am again, looking at a script that's grown larger than I expected. It's loaded with a page or two of file-scope lexicals at the top, followed by a bunch of functions that operate on them (many take no arguments and return no values), followed by a short "main" section at the end that uses those functions. This happened because the script started out as just a short shell-scripty thing. "Do this, ask if I should do that, then do the other thing, and so on. Oh, but I need to save some state, so here's a global for that... and also a global for this... well, may as well rope this bunch of logic off in a function...". It all started so innocently. The program doesn't (yet?) have many things in it that could be thought of as "objects", per se. Though, even if I did create a class and pulled a few strands of the bowl, there still would be plenty of spaghetti left over that needs straightening out. So, what are the core points of good procedural design? I realize that functions modifying globals is not a terribly good idea, but am not sure how to escape it. I also realize that OOP isn't the cure for everything, and don't want to rush headlong into creating classes unnecessarily. In reply to What are the core points of good procedural software design? (functions, code structuring) by Anonymous Monk
|
|