[boost] Re: Naming conventions

From: Nicolai Josuttis (nicolai.josuttis_at_[hidden])
Date: 1999-06-01 09:31:12

I think, we all agree that we DON'T follow the standard scheme.
So let me summarize MY NON-BINDING actual naming scheme proposal for boost:

File Names extensions:
 .cpp  for source files
 .hpp  for header files

Base names: 
 Should the basename follow the std model?
 IMHO not. E.g. if I declare some functors
 and name the file functional or better functional.hpp
 nobody else could use this name for other functors.
 In addition we have a name clash for supplementary stuff. That's bad!
 So for example, use compose.hpp or hash_map.hpp or ...

Namespace:
 always: boost

header preprocessor wrapper:
 something like:
   #ifndef BOOST_NAME_HPP
   #define BOOST_NAME_HPP
        ...
   #endif /*BOOST_NAME_HPP*/

Identifiers:
 I'd suggest as only hint:
   lower_case for variables and functions (things that have storage).

 Any other scheme for anything else.
   For example, HashMap or hash_map or compose_t.
   This is because there are good reasons to prefer one scheme over
   the other (e.g. compose_t would be a good internal type name, but
   hash_map_t would not be very convenient).

Beman Dawes wrote:
> 
> At 06:18 PM 5/31/99 +0200, Valentin Bonnard wrote:
> 
> >I think we should adopt some lexical conventions if we want
> >a consistent naming in Boost.
> >
> >I suggest to follow Nathan's advice:
> >- lower_case variables and functions
> >- UpperCase types [actually mixed case, with first letter always
> uppercase]
> 
> I use that convention myself for applications programs for many
> years, and am happy with it.
> 
> But most boost submissions so far have been designed to work closely
> with the C++ Standard Library, so have followed its naming
> conventions.  Some are likely to be proposed for inclusion in the
> five year revision to the standard, so the authors of these will be
> adamant about following the standard's naming conventions.
> 
> So it doesn't look like a good idea to me to flatly say "do it one
> way" or "do it the other way".
> 
I agree. In addition, it is better, we have some code instead
of taking too much time on this issue.

-- 
Nicolai M. Josuttis
Solutions in Time
http://www.josuttis.de/
mailto:solutions_at_[hidden]
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications