|
Dan wrote: > ... > > Summary: > > It checks to see if the order is valid. > > Maybe. Are you sure? Remember, you don't know the programmer who wrote it. > ... So you check it once, and see that indeed it does that, and then you don't have to check it again (at least during this particular maintenance session). While you're checking, you probably have a look at a few more of the subprocedures coded near ValidOrder, to see if they also do what the names suggest. You gradually learn which procedures do what they say they do, and you gradually start saving time re-reading code. In debug, with unfamiliar procedures you step in once to see what's going on, then step over unless you spot something suspicious inside it. If the procedure doesn't do what its name suggests, shouldn't you do something about it? Change the name, fix the code, whatever. Just because you have a bad procedure now doesn't mean you have to have one in the future. Fixing it so the procedure is re-inlined everywhere it's called doesn't seem like a good solution to me. I think you implied that it's ok to have procedures with many lines of code, but do these longer procedures have different criteria for correct naming and for only doing what they say they are doing? Seems to me the number of lines is completely irrelevant to the question of how you handle a procedure-call line while doing maintenance.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.