On 9/10/07, David A. Wheeler <[EMAIL PROTECTED]> wrote: > > I'm trying to figure out what problem is being solved. > > If the problem is that "the names are hideously unclear and thus making > maintenance difficult", then trading one mysterious abbreviation for another > mysterious abbreviation
That's pretty obvious. Did you have a specific suggestion? The example of globals: tcc contains many routines that run for hundreds of lines. If globals are not namespaced in some way then every time you encounter one at, say, line 237 of a routine you have to (re)examine all 237 lines to see if it was locally defined, etc. That's not only a time sink, it's extremely annoying, at least to me. The other major problem /for me/ is that the source text is an unreliable guide to the process logic. You can't trust a routine to do what it's name would seem to imply, and you can't figure out what data structures mean without spending many hours trying to figure out what the code does with them. At least I can't. Basically the code is written in a kind of private idiom, whose primary audience is the machine, not people; it may be fine code but it takes an inordinate amount of time to decipher; in the end you have to more or less memorize the whole blasted thing in order to be able to work with it. YMMV. > > I think most users don't CARE what the internal names are, so spending much > time on I'd say that's a pretty safe bet, considering "most users" never lay eyes on the source. But the point of cleaning up source text is not to help users (directly), it's to help programmers by reducing the amount of time it takes to understand the code. I gather from this and other emails that my goals are not entirely aligned with the project's, so I 'm going to take Rob's advice and go away and work on my own copy. I'm actually beginning to lean toward the rewrite-from-scratch approach, God help me. If I come up with something (most likely documentation) that might be useful I'll post a note. -g _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
