Re: [Tinycc-devel] naming conventions

[Rob Landley]

On Monday 10 September 2007 5:11:37 pm David A. Wheeler wrote:
> > > > > 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.

The problem I was trying to solve is the old name was too short to grep for, 
since it comes up in "char" and "search" and a bunch of other places.

Now that it's greppable (and search and replacable), it could be replaced with 
any name but I no longer have much interest in doing so.

I'm more interested in the larger problem of grouping our globals together 
into structures.

We need at least one for the parser ("parser"), one for compilation state we 
remember about the program so far ("compile" maybe?), one for the code 
generation backend ("backend"), and the TCCState we have now which is control 
information telling the compiler how to behave, what environment it's running 
in, where its search paths are, and so on).

Then if we change the code to have one global pointer to each structure, and 
measure the resulting overhead from the extra dereferences to make sure we 
can live with it...  (If all four are in one cache line it should be 
negligible overhead on x86.  Might suck on arm but hopefully not _too_ 
badly...)

The code size and runtime overhead is what I'm worried about, but I point out 
that we already have TCCState, there are various existing code shrinkages we 
can do that a cleanup will help with, and most of this data isn't on the hot 
paths the hottest of which is probably the character-by-character processing 
(using ch and tok) which already has multiple nexted function calls, some 
with very little justification...

> 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.

And one reason I made the change as small as possible, so the patches are 
easier to fixup (since I'm probably the one who'll have to 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.

My definition of incomprehensible is "can't grep for it".  The old ch was bad 
enough it was used as a function argument (hiding the global) more than once.

Beyond that, grouping globals in structures is probably enough of a cleanup to 
be worth the churn, but renaming existing symbols much less so.

> 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.)

C _is_ a language that supports namespaces.  It's called "structures" 
and "files" (with static). :)

<rant>
C++ is a language that tries to solve mental problems with syntax.  
Programmers who couldn't keep their symbols from conflicting in C (which 
already has struct and static) embraced classes and object oriented 
programming as the one true way to group everything and keep namespaces from 
conflict.  But then classes turned out not to be enough in practice, because 
their programs were still horrible tangled messes of disorganization that 
didn't compile, so they added namespaces to the language!  Did this make them 
better programmers and stop all that C++ code out there from being horrible 
tangled messes?  Of course not.

Tools do not make code organized.  Programmers make code organized.  A word 
processor won't make you a better writer than a text editor will.  (Or for 
that matter, a pencil.)  It solves _different_ problems.
</rant>

> 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.

That's what I've been spending my time on. :)

I do want to clean up and refactor the code, but for different reasons and 
with different results.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.