Let's Build a Procedure
** This thread discusses the article: Let's Build a Procedure **
Hi Ralph! > I disagree with that particular advice, buck. Not a problem - that's why we have discussion lists! :-) > Too many IT people push itsy bitsy functions, > code only the size of the screen, and other > programmer oriented constraints on usefulness of code. You've hit the nail exactly on the head here. Generally the point of these limitations on the programmer are there because the programmer can't hold the whole thing in his head at once. There is genuine room for disagreement on exactly how big is 'too big' and how small is 'too small.' In general though, I find that large parameter lists are a red flag in the 'too big' direction. For most of us RPGers, we're accustomed to very large programs, and many small units seem overly difficult to manage, so we stick to larger code units rather than smaller. > Examples are always pathetic and usually a > freakin formula or something, with one return > parm and not even a nod to reality. It's true that examples are usually off the wall, but that is not the fault of the concept - just the teacher. To me, the true value of subroutines is measured by the way the programmer's thinking shifts from large, amorphous blocks to smaller, concise functions. If you look at the way the rest of the programming industry writes code, you'll find that many small-ish functions is the way things have shaken out over 20 years ago. Everything from small 1 or 2 screen programs to mammoth applications like the Social Security system are written this way. On the other hand, if your shop has a good set of practices in place to do this sort of thing with a small program (no LR, call it one last time to shut down, naming conventions for the scratch variables to hold the results) then I say Bravo! Because you're already reaping the benefits of reasonably small code blocks and thinking in terms of functions. --buck
** This thread discusses the article: Let's Build a Procedure **
Hi Ralph! > I disagree with that particular advice, buck. Not a problem - that's why we have discussion lists! :-) > Too many IT people push itsy bitsy functions, > code only the size of the screen, and other > programmer oriented constraints on usefulness of code. You've hit the nail exactly on the head here. Generally the point of these limitations on the programmer are there because the programmer can't hold the whole thing in his head at once. There is genuine room for disagreement on exactly how big is 'too big' and how small is 'too small.' In general though, I find that large parameter lists are a red flag in the 'too big' direction. For most of us RPGers, we're accustomed to very large programs, and many small units seem overly difficult to manage, so we stick to larger code units rather than smaller. > Examples are always pathetic and usually a > freakin formula or something, with one return > parm and not even a nod to reality. It's true that examples are usually off the wall, but that is not the fault of the concept - just the teacher. To me, the true value of subroutines is measured by the way the programmer's thinking shifts from large, amorphous blocks to smaller, concise functions. If you look at the way the rest of the programming industry writes code, you'll find that many small-ish functions is the way things have shaken out over 20 years ago. Everything from small 1 or 2 screen programs to mammoth applications like the Social Security system are written this way. On the other hand, if your shop has a good set of practices in place to do this sort of thing with a small program (no LR, call it one last time to shut down, naming conventions for the scratch variables to hold the results) then I say Bravo! Because you're already reaping the benefits of reasonably small code blocks and thinking in terms of functions. --buck
Comment