Why does it matter what things are called if the name of the thing might be a lie anyway? I'm going to have to check what it does anyway!

I've adopted what I call the square rule (I've never heard it called anything else): The length of the name is the inverse of the square of the extent, and the frequency of its use.

Thusly, a short name like "i" might be acceptable if the number of source code bytes between all the users of the variable are small, such as:

    {int k=0,i=0;for(;i<500;++i)if(do_something(i))++k;return k;}

or if the variable is used almost everywhere in the program: I might have:

    register int*G asm("r12");

and be okay with it if nearly every function in my program is using G in some way. If you've heard of a similar rule to "huffman-code" your variable names, you can imagine I've simply adopted a dictionary selection strategy.

That works for me, but in a large program it breaks down, because a large program may have multiple names for the same operation, and with multiple programmers (even following this rule) it may be difficult to predict the names chosen by other people on the team. That leads to code bloat, because programmers will often invent similar utilities (but for different purposes) with different names.

I'm working with a guy at the moment who is fastidious about naming. He's the naming czar in this project, and almost nearly every function in this application has had its name blessed by him, so they're unusually consistent, to the point whilst I can't quite predict what something might have been called when searching to see if someone has already written a function I might like to use, I can ask him what something should be called and if it exists it will certainly have that name.

That's cool! That's also a bit of a new/interesting experience for me, and even though I see some value in it, it doesn't scale, and I don't know how to replicate it. I would see value in a book that can teach how to name things that need good names, that team members who can carefully follow the strategy can end up with consistent names so we can find each others hard work faster, so I hope this book (the author is describing) addresses this point, instead of the inverse: crappo-drivel about predicting a functions' (or definitions') implementation from its name, something I see a lot of bloggers wax on about, but has negative value to me.