Jamie, I'm not Andy, but I am the author. Your points are well taken, but due to the fact that this is a PICLIST and not an IBM CLONE LIST, I naturally assumed we were talking about PIC programs. Most of the programs I have written are less than a hunderd lines or so. And I wouldn't call it spaghetti code at all. They are rather logical and coherent, and most importantly, they do the job they were designed to do. And they are stable and well behaved. As far as maintaining them, the changes are minimal. But the point is that if I need to divert from the mainline, it makes little difference what method I use to get there and back, as long as I get there and back correctly. In a program for an IBM CLONE or other such machine, by all means the choice of detour from the mainline is important, and has to be chosen carefully to maintain effeciency and continuity, especially with tens of thousands of line of code to concern yourself with. And in PIC programs, with the PIC's limited resources, this choice is somewhat open. Which proves my point that it makes little difference which method you choose, as long as you get the results that you are looking for, and the stability to maintain those results. About professional programmers.. I'm not one by trade or confession. I do some PIC programming on a professional level as a coincidental part of my employment, and I do some for relatives, and friends, and for my own projects, but I don't do it as my main source of income or my main occupation. So, therefore, the ethics and code of good programming conduct for professional programmers is mostly unimportant to me. So, bottom line from my point of view..... 1) We are talking about PIC's here, with limited resources. Especially Memory (Program Store and RAM) 2) With line #1 in mind, it seem easy for me to stay with my original assesment of there not being much difference which detour method is chosen to perform a given task, providing the method you choose can give you the results and stability you are looking for. 3) The points you make about professional programmers and programs of tens of thousands of line of code are well taken, and I agree with the importance you have placed with them. 4) I believe I do good work, and my superiors apparently think so too, (Some of which ARE professional programmers BTW),as they are often telling me so. And I'm sure you, as a professional programmer, do a good job too in the code that you write. It is important for the author of a given piece of code to be able to go away from it for a while, and at some later date, come back to it and understand what he (she) was trying to do when it was written. But for PIC programs, there is less of a chance of the author of a piece of code not remembering what it was supposed to accomplish, and how it was supposed to accomplish it's job or function. At least for me, this is the case. Of course, I do quite extensive documentation as I go. And this in fact may be the reason that other people could pick up from where I left off and not have much trouble in maintaining the code I have written. This and the fact that the code is typically one hundred lines or less. I don't mean to step on anyones toes with my rants and raves on this list, but I honestly don't understand some of the arguments that people here present to substantiate their point of view. And don't anyone think for a minute that I think I'm infallible. I'm probably high on the list of fallible (?) people. But, from my point of view, some of the arguments on this list are so petty, that I sometimes get irritated beyond belief. That's when I start ranting and raving. And by all means, if you have what you believe are good justifications for what it is you say, , let me know. I'd be more than happy to listen. Jamie did, and he makes good points with what he says. How else can we grow intellectually unless we have a dialog about some mutual subject from time to time? Anyway, thats my take on it. I'm done again. Regards, Jim So any arguments about professional programming, directed to me, are basically wasted because by not being a professional programmer, I On Wed, 13 September 2000, Jamie Dainton wrote: > > Hello Andy, > > Wednesday, September 13, 2000, 12:00:20, you wrote: > > >> The argument about it being easier or more proper to maintain a > >> program using one over the other is ludicrous at best. Why is it > >> easier to use a CALL for instance than a GOTO? Or a GOSUB in place > >> of a CALL? This seems rather dumb to me. Most of the programs I > >> have written, regardless of language, I get to maintain. No problem > >> there right? > > Because when a called sub or function gets to the end or return > statement it returns to the line after it was called. This can *not* > be guaranteed with GOTOs. Also how big are these programs. Most of us > programmers find it hard enough to go back to a 10000 line, well coded > and commented procedural program after a few months of not looking at > it. The other point is a professional programmer should always write > code as if they're going to be graded on it or someone else will have > to maintain the software. Then there is the team programming where > more that one programmer will be working on the project. How does your > sloppy, spaghetti logic code fit in then? When using small processors > such as pics with a shallow stack GOTOs are acceptable. In proper > systems they should never be used at all. VB programmers among you > will think of VBs terrible error handling. On Error Goto Errohandler. > Well done M$, perfect bit of thought. > > > -- > From Jamie Dainton > Wednesday, September 13, 2000 13:42:21 > The Bat! 1.46 Beta/5 > Windows 98 4.10 2222 > > mailto:pgp@dainton.org.uk?subject=sendKey > > -- > http://www.piclist.com hint: To leave the PICList > mailto:piclist-unsubscribe-request@mitvma.mit.edu jim@jpes.com -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu