Bryan R Harris wrote: > > I'm not even sure how to ask this question, but here goes: > > I struggle knowing how to structure my code, what things belong as their own > subroutines and what things can stay in the main script. How do the smart > guys make these decisions? > > For example, let's say I need to: > > 1. Read a complex file > 2. Populate a complex dataset > 3. Accept user input > 4. Based on user input, either modify or add to dataset, or quit > 5. Update files on disk > 6. Go to step #3 > > Which steps should be their own subroutines vs. just writing them into the > main part of the script? And how did you make that decision? > > Seems like a waste to do step 2 in a subroutine since we only do it once, > but it does fill the main body of the script with code-noise that makes it > harder to debug overall logic problems... Not much logic here, but > certainly in more complex scripts. > > Any suggestions? Where can I read more on this stuff? What questions > should I be asking that I'm not smart enough to ask? > > TIA. > > - Bryan
Well, there is one school of programming that insists that no subroutine should be larger than 42 lines (see, it is the answer to everything). I would separated the user I/O and the dataset I/O into their own modules so that future changes to them will be isolated. -- Just my 0.00000002 million dollars worth, Shawn Programming is as much about organization and communication as it is about coding. I like Perl; it's the only language where you can bless your thingy. -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
