On Mon, Dec 29, 2014 at 9:59 AM, Branko Čibej <br...@wandisco.com> wrote:
> On 29.12.2014 13:59, Stefan Fuhrmann wrote: > > Hi there, > > > > FSX code contains various violations to our naming rules, > > mostly taken over FSFS. I thought about a scheme that > > complies to our rules but also refines them. > > > > I'd like to amend our coding guideline with the following > > suggestions (not as a strict requirement). The first one is > > actually "new" while the other two have already been used > > by various portions of our fs_* libs: > > > > 1. Use the svn_ prefix only for identifiers meant to be used > > by other libs, i.e. only for declarations in the ./include sub- > > tree. We currently lack that distinction and it lead to minor > > confusion in the past. > > If it's a non-static identifier (i.e., if it can possibly be exported > from some library), then we have to retain the svn_ prefix in order to > reduce the chance of name collisions in downstream uses. > Right. It comes down to visibility. If any other toolchain, loader, compiler, whatever... can *see* one of our symbols, then we should ensure the svn_ prefix is present (or SVN_ or SVNCamel, of course) >... Cheers, -g
