Is the lcl_LocalFunction naming convention useful?

[Lubos Lunak]

On Tuesday 09 of October 2012, Miklos Vajna wrote:
> On Tue, Oct 09, 2012 at 09:29:45AM +0300, Tor Lillqvist <tml at iki.fi> wrote:
> > > > Where did this lcl_ convention come from?

 From a codebase that is ridden with Hungarian notation and other 
eye-"pleasing" features?

> > But how is the fact that you see that some lcl_Function is "local"
> > make it easier to understand what the function does? Isn't it only
> > unnecessary visual fluff?
>
> Example: if it's lcl_Foo(), I just search in the local file. If it's a
> method, I use ctags to look up the function definition.

 Which, as you yourself have said, does not really work.

> > Anyway, my main point was not that we should drop the "lcl_" prefix,
> > but that we should make these functions *actually* local, also for the
> > tool-chain, i.e. either static or in anonymous namespaces.
>
> Agreed, if Lubos' compiler plugin could check for lcl_ functions that
> are not static / in an anon namespace, that would be great, I guess. :-)

 The plugin could do it, but Lubos would prefer if it didn't. I don't think 
this visual noise is worth it. What about class private methods, for example? 
According to the logic of this, they should be lcl_ too, but they can't be 
file static. In general, either you'll have a number of methods that should 
be named lcl_ but aren't, or we'll end up with half of our functions called 
lcl_ where the visual noise will far outweight any possible gain.

-- 
 Lubos Lunak
 l.lunak at suse.cz