Brian Blais wrote: >On Apr 18, 2009, at 5:44 , Hendrik van Rooyen wrote:
>>to untangle some spaghetti code. He did not mention if >>the spaghetti was actually doing it's job, bug free, which >>IMO is the only rational test for the quality of a piece >>of code, because it is the reason for its existence. >>The aesthetics are, like all aesthetics, a matter of opinion. > > >Actually, I strongly disagree with this statement. >In my experience, there has been very very few >pieces of code that I've written that I hadn't wanted >to *modify* at some point: extend it to a new set of >circumstances, cover a different case, change the >output, etc... The quality of a piece of code is not just >if it works right now, but if you can reasonably extend >it for the future. Your experience is different from mine - in what I mostly do, which is struggling around in embedded assembler, by the time the thing "works" it is stable, and I very seldom have to go back to fiddle with it. On the other hand, I understand what you are talking about, but I think that the origen of the frustration that one feels when having to battle with some old code, is actually inside oneself - the code is the same, but I have changed, and I am no longer the same as I was when I wrote it. >I toyed with Perl for a year or so, but couldn't give it >my full attention. As a result, every few weeks when I >wanted to modify what I wrote, I had to re-learn the >code all over again because the syntax was so terse. >The same is true for the typical use of a goto: you have >to relearn the program, because the flow jumps around. >It's not just about aesthetics, but about being able to >work with a piece of code. In my defense of the goto, I would like to make clear that I do not support its use to produce spaghetti. In general, muddled thinking, coupled with expediency, is what I think are the true precursors of spaghetti code. The goto is an innocent tool that can be used for good or evil. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
