|
Joe Pluta wrote: > If a chunk of code has no parameters, and affects only global > variables like fields on the screen, then how exactly is it better to > wrap that chunk of code in a procedure? Initially, it gains me nothing ... but I now have the freedom to add local variables, parameters if they are needed in the future, etc. Unless absolutely necessary, I probably wouldn't have it operate on global variables anyways, I'd pass in the information that's needed, so I can 'black box' the routine (and possibly externalize it in the future). > You have to add the begin and end procedure as well as the rather > redundant one-line prototype at the beginning of the code. It gets > even more painful with /free, since you have to also add the /free > and /end-free, since the P and D specs aren't free-form. Eh, no biggie, IMHO. > And procedures can be misused most horribly. One of the worst > offenses I see is procedure with a bunch of return opcodes strewn > throughout it. At least with a subroutine you can stick a breakpoint > on the ENDSR and know it will get there. So can indicators ... and we all know how powerful indicators are. ;) > It's when people get zealous and start trashing other people because > they use subroutines that my blood pressure rises. True enough ... I'm currently trying to _gently_ encourage my co-workers to use more procedures ... but only where they obviously make more sense. david
This mailing list archive is Copyright 1997-2026 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.