On Tuesday 09 of October 2012, Miklos Vajna wrote: > On Tue, Oct 09, 2012 at 09:29:45AM +0300, Tor Lillqvist <[email protected]> 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 [email protected] _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
