style wrinkle with private member names

[marlowa]

I notice that private member names have a leading underscore in POCO. IMO this is VERY inadvisable. The reason this practise (which is not confined to POCO) is banned by several coding guidelines is because of what the std says about leading underscores being reserved for compiler implementation use. Believe it or not, I have seen the advise floated by a project that went on to experience compilation errors because of it (it was on HPUX using their aCC compiler if I recall correctly). So this danger is not merely theorectical.

Will POCO please consider changing this. Foundation/utility libraries such as POCO can get very wide reuse and be deployed in a large number of different environments. It is possible that one day a POCO header will be included by an application that either gets nobbled directly by this issue or indirectly depending on which system headers it includes.

The trouble with waiting until this problem actually bites for real is it tends to be worked around on a case by case basis. As these cases gradually accumulate over time it will detract from the overall quality of the code.

These are only private member names and so a change will not affect the public interface. I hope POCO people will consider this.

-Andrew Marlow

[alex]

Andrew,

AFAIK, this is only concern if you have underscore followed by uppercase letter.
It's ultimately up to Guenter, but personally, I find leading underscore more aesthetic than the trailing one.

Alex

[alex]

Sutter says about the topic :

"The more specific rule is that any name with a double underscore anywhere in it __like__this or that starts with an underscore and a capital letter _LikeThis is reserved. You can remember that rule if you like, but it's a bit easier to just avoid both leading underscores and double underscores entirely."

Appinf Coding Guide deals with the issue in rules 31-33.

[guenter]

There are different opinions regarding the validity of leading underscores in class member names. The C++ standard explicitly states that leading underscores are not allowed in global names. Class members are not global, therefore this rule does not apply to them. Experience with a variety of different compilers has not shown any problems yet.

The only potential problem I see is with ill-defined macros coming in from third party header files. But this is a general problem with all C/C++ projects (just look at the mess that creates.

So for now I'd like to keep things as they are. If we should run into major problems I'll consider changing that, but for now we have more important things to do ;-)