Reply to thread

Message: [QUOTE="James Dow Allen, post: 2383335"] Putting this piece of code in context, here's the very first sentence of my lesson9.htm: Given the above context, I'll take this as a compliment! :-) The 90-line source program in question is *much harder* to read or understand than the average 90-line source program. But that's not a fair comparison. The question should be, how does the net readability of my code compare with another program that *solves the same problem*? I posted the link to this peculiar code almost as a joke, but now it occurs to me that it might pose an interesting challenge for programmers in general, or c.l.c'ers in particular. It would be instructive for me, and perhaps others, to compare with a properly coded version, but we'll need that properly coded version. (It should be a full program that solves Waldo's Nim; otherwise I'm afraid fragments will be posted that simply can't accomplish what the peculiar code does.) Write the program the way it should be; let c.l.c'ers vote on the best solution. I'll be happy to post the winning submission at my website (unless the winner feels this would be a booby prize. :-) It shouldn't take long to do it: as Mr. Torek pointed out, the peculiar part just sets up a sparse array, and the rest is a very simple algorithm which isn't the issue. (A heuristic improvement may exist, but that would be a separate topic for alt.brain.teasers.) A thread based on such a ``contest,'' might be fun for c.l.c, and you should be grateful to me for playing the buffoon whose code needs improvement. But first, let me summarize my feelings about my own code: (1) it was written for play not pay; paid code would have been improved in some ways (though I'm afraid it still would have used a macro like NFOR). (2) nesting 12 loops seems like the natural and best way to write the program; since the loops are essentially identical, using a macro seemed right; with these decisions, packing the calloc() into the for-statement substantially simplified the syntax. You may disapprove, but the intent was to clarify the code, not obfuscate it! (3) some aspects of the code others find ``bad'' are indeed bad. My question is whether the cure would be worse than the disease. We all agree global variables are bad, but we use them when the alternative is dozens of unwieldy function arguments. We all agree long functions are bad, but some of us use them when factorings aren't really helpful. And I'd like to see the "proper" version of this program before agreeing it's better. (4) coding involves trade-offs, and shouldn't be dictated by dogma. (as an extreme example of dogma, one can find old messages in c.l.c with the claim that *longjmp()* is better than *goto* because it's a function, not an (evil) keyword.) (5) as most readers realized, the code indulged a whimsical (or perverse) love of minimalism. I hope some of you also find programming *Fun*! * * * * * * * * * * * * * * * Someone wrote, in effect: [I've rearranged the 13's so the numbers fit size_t.] Errh, my contest offer is sincere, but submissions will be expected to compile and execute on present-day computers. Someone else wrote, in effect: Was *this* a troll? I personally see nothing wrong with nesting a dozen loops, especially here when the loops are equivalent (just handling different axes of a multi-dimensional structure), but if there *is* something wrong with it, fitting tabs onto paper or screen can't be the problem, can it? And why would anyone think adding 18 indentations to the code is a good idea (unless your 4th grade programming teacher used to hit you with a ruler when you didn't indent every sub-block)? Finally, although we've all used cc -E | indent to decipher obfuscated code, the idea that code like #define NFOR(N) something_very_complicated_but \ whose_complexity_doesn't_involve_N_or_submacros NFOR(1) NFOR(2) NFOR(3) NFOR(4) NFOR(5) NFOR(6) NFOR(7) NFOR(8) NFOR(9) NFOR(10) NFOR(11) NFOR(12) calls for the `cc -E | indent' tool strikes me as inexplicable. James [/QUOTE]

Verification