On Sun, Apr 19, 2009 at 04:35:27AM EDT, Hendrik van Rooyen wrote: > 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. +1 .. obfuscated code never remains bug-free for long. > 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. Intellectually, assembler programming is the less demanding since its level of abstraction does not go any further than mapping a few binary numbers to a small set of usually well-chosen mnemonics. Unless it features a powerful macro-language that lets the apprentice create his own high-level patois on top of the assembler, that is. > 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. How true. At least goto's have the merit of naming their target. I have dealt with C code built on the original author's partiality for 200-line+ nested loops where it looked like every other line or so was either a "break" or a "continue", goto's without the name that don't clearly state where they are going. Thank goodness he was not familiar with setjmp/longjmp. :-) CJ -- http://mail.python.org/mailman/listinfo/python-list
