are namespaces of boost libs required to be lowercase?
Hi! If someone wants to contribute code to boost: Is she required to provide the names of all namespaces lowercase? E.g. someone provides Elefant, the big library. Is she allowed to have namespace Elefant and perhaps namespace Elefant::Private, etc. I could not find any hint except this here, which did not really help me, since I do not know the standard library's conventions. Any link/ hint appreciated: -- citation from the boost docs -- "Naming conventions rationale The C++ standard committee's Library Working Group discussed this issue in detail, and over a long period of time. The discussion was repeated again in early boost postings. A short summary: Naming conventions are contentious, and although several are widely used, no one style predominates. Given the intent to propose portions of boost for the next revision of the C++ standard library, boost decided to follow the standard library's conventions." best regards, Markus
At 11:12 AM 2/26/2003, Markus Werle wrote:
If someone wants to contribute code to boost: Is she required to provide the names of all namespaces lowercase?
E.g. someone provides Elefant, the big library. Is she allowed to have namespace Elefant and perhaps namespace Elefant::Private, etc.
The strong preference is for all lowercase with words separated by underscores. Thus: namespace boost::elefant ... namespace boost::elefant::detail
I could not find any hint except this here, which did not really help me, since I do not know the standard library's conventions. Any link/ hint appreciated...
Hum. The current text isn't very clear. I've reformatted it in CVS. See below. HTH, --Beman --- reformulated wording --- Use the naming conventions of the C++ Standard Library (See Naming conventions rationale): * Names (except as noted below) should be all lowercase, with words separated by underscores. * Acronyms should be treated as ordinary names (e.g. xml_parser instead of XML_parser). * Template parameter names begin with an uppercase letter. * Macro (gasp!) names all uppercase and begin with BOOST_.
Beman Dawes wrote:
Use the naming conventions of the C++ Standard Library (See Naming conventions rationale):
* Names (except as noted below) should be all lowercase, with words separated by underscores. * Acronyms should be treated as ordinary names (e.g. xml_parser instead of XML_parser). * Template parameter names begin with an uppercase letter. * Macro (gasp!) names all uppercase and begin with BOOST_.
A hard burden You lay on developers. So maybe the code has to be piped through a code de-beautifier when it comes to a boostification. IMHO (UsingThisConventionHere == CommonPracticeElsewhere) Markus
Markus Werle said:
Beman Dawes wrote:
Use the naming conventions of the C++ Standard Library (See Naming conventions rationale):
* Names (except as noted below) should be all lowercase, with words separated by underscores. * Acronyms should be treated as ordinary names (e.g. xml_parser instead of XML_parser). * Template parameter names begin with an uppercase letter. * Macro (gasp!) names all uppercase and begin with BOOST_.
A hard burden You lay on developers.
It's not a burden.
So maybe the code has to be piped through a code de-beautifier when it comes to a boostification.
That's a bit harsh. If *you* don't care for the style, you're welcome to that opinion, but voicing it in this manner isn't going to help anyone to agree with you.
IMHO (UsingThisConventionHere == CommonPracticeElsewhere)
It's not common practice everywhere (I know of as many places that follow the C++ standard naming conventions as those that follow what I'll call "Java" naming conventions). But the important thing is that the whole point of Boost is to be a test bed and development area for libraries that *might* be considered for inclusion in the standard. As such, we have to follow the standard naming conventions. -- William E. Kempf
William E. Kempf wrote:
It's not common practice everywhere (I know of as many places that follow the C++ standard naming conventions as those that follow what I'll call "Java" naming conventions). But the important thing is that the whole point of Boost is to be a test bed and development area for libraries that *might* be considered for inclusion in the standard. As such, we have to follow the standard naming conventions.
I like the fact that boost follows the standard naming convention. We use boost as an extension to the standard and as such, can easily differentiate between our code (which follows more closely your afformentioned Java convention) and STL/boost etc. Cheers Russell
William E. Kempf wrote:
Markus Werle said:
[...] A hard burden You lay on developers.
It's not a burden.
Well, it depends: once You _have_ a library written in the other style and once You have tested it (maybe certified it) and started to let other programs depend on it, a style change might be at least very annoying, because names from the lib appear in the user's code. If the dependency tree is large, that _is_ a burden.
So maybe the code has to be piped through a code de-beautifier when it comes to a boostification.
That's a bit harsh.
It was not meant to be harsh. Maybe throwing in my opinion about what is beauty was a bad idea, so if You have a shell prompt at hand: # cat mypost | sed -e s/de-beautifier/converter/g
If *you* don't care for the style,
I care. That's the reason for the OP.
you're welcome to that opinion, but voicing it in this manner isn't going to help anyone to agree with you.
I am not on a jihad for some code style, but rather on an investigation tour how much it takes to boostify existing code. I just sometimes cannot hold back my comments on things I dislike to be as they are. Please assume from now on that I do not want to try to change the boost rules (I give up before trying) but rather find a convenient way to obey them without sacrificing too much.
IMHO (UsingThisConventionHere == CommonPracticeElsewhere)
It's not common practice everywhere
No contradiction here. Unfortunately it is common pratice for some very famous C++ books like Herb's, Nicolai's, Andrei's and David V.'s books. That is why I talked about a heavy burden. At least David V.'s book will be without concurrence for a long time, so expect some programmers to GetUsedToThatStyleBeforeTheyCommitCodeToBoost.
But the important thing is that the whole point of Boost is to be a test bed and development area for libraries that *might* be considered for inclusion in the standard. As such, we have to follow the standard naming conventions.
Or change _them_? <- yes, it's a joke!!! Seriously: This argument is strong enough to stop the discussion about styles immediately, therefore let us find satisfying solutions for the follwing case: If some guy has written code that he thinks is good enough to expose it to a boost review and the only problem he sees with his lib is the completely different naming convention. What do You propose him to do? I see several possibilities: 1. The standard rules, AFAICS, are meant for the _user_ interface (I guess this from the bogus names some vendors use to make their internal code completly unreadable) So would it be acceptable if some boost::lib is rule-compliant in the interface and for the "public" namespaces, while retaining the other style in the brain-damaging internals, where some programmers might need them to understand their own code? Minimalist's approach: only _add_ aliases for the user interface that follow the convention: namespace conformant_garbage_c = GarbageC; ... template typedefs at hand, soon ... 2. Another possibility - which is cleaner and maybe to prefer - would be the automatic code conversion. If You have a convenient tool for that, I would like to test it on some code (e.g. Loki, Daixtrose) to see the effects. The sed approach from above may help, but I could not yet extract from the docs how to apply regexes such that MyOldStyle becomes my_old_style. I think this could be a 5-liner with boost::regex. I haven't used that lib until today, so I say ThankYou (thank_you) for any code snippet which may serve as a starting point. best regards, Markus
At 06:55 AM 2/28/2003, Markus Werle wrote:
I see several possibilities:
1. The standard rules, AFAICS, are meant for the _user_ interface (I guess this from the bogus names some vendors use to make their internal code completly unreadable)
So would it be acceptable if some boost::lib is rule-compliant in the interface and for the "public" namespaces, while retaining the other style in the brain-damaging internals, where some programmers might need them to understand their own code?
I'm not sure that exact question has been asked before. My immediate reaction is that naming conventions are much more important for the public interface than for implementation internals. --Beman
participants (2)
-
Beman Dawes -
Markus Werle -
Russell Hind
-
William E. Kempf