Re: [Tinycc-devel] naming conventions

[David A. Wheeler]

> > > > In fact, it's pretty much guaranteed to
> > > > confuse, since the notion of a lookahead ("following char = fch?") is
> > > > part of the domain knowledge.  I'm afraid I don't like fch much at
> > > > all.  Sorry...

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 doesn't help.  If your purpose is to make the code 
clearer, use something clear like "token" instead of "tok" if you think "tok" 
is unreadable.  I find "tok" clear enough, frankly - in code for a compiler, 
what else would it be?  Widespread name changes cause patches to fail, 
unfortunately, which is one reason people often don't do it.  I suggest that, 
at MOST, find the few "most incomprehensible names" and just change those, 
otherwise, we'll be drowning in name changes instead of more useful 
improvements.

If the problem is "pollution of namespace means users have link problems", 
which is what I guess the prefixing is for, I see renaming as far less 
valuable.  If you compile from the command line (inc. as a script), none of the 
names internal to the compiler matter.  Even if you embed the compiler (link it 
into another program), I think it's unlikely that anyone would use many of the 
compiler names, and all that prefixing would make the code hideous to look at.  
Languages that support namespaces (C++, Java, Ada, etc.) normally include ways 
to auto-search selected namespaces.  C doesn't have direct namespace support, 
so you'd have to add the prefixes everywhere, in all uses, which would make the 
code hideous.  Perhaps there are a few variables or function calls whose names 
are more likely to overlap, but if so, just rename those.  Is anyone embedding 
tcc and having this problem?  If not, this may be work to solve a non-problem.

I think most users don't CARE what the internal names are, so spending much 
time on this is more likely to hinder than to help.  I'd rather see known 
functional bugs, weaknesses, and omissions fixed, than see much time spent on 
renaming stuff.

--- David A. Wheeler