generic programming: (in?)compatibility of CamelCase and snake_case

Discussion in 'C++' started by Jeff Schwab, Mar 22, 2008.

  1. Jeff Schwab

    Jeff Schwab Guest

    Some people who clearly understand generic programming (probably a good
    deal better than I do) seem to prefer CamelCase, even when trying to
    interoperate with the C++ standard library. One striking example is
    Andrei's book Modern C++ Design. What is the reason for using
    CamelCase? Since static identifiers effectively define the interface
    supported by each type, how is syntactic compatibility maintained
    between CamelCase libraries and the snake_case STL?
    Jeff Schwab, Mar 22, 2008
    #1
    1. Advertising

  2. Jeff Schwab wrote:
    > Some people who clearly understand generic programming (probably a
    > good deal better than I do) seem to prefer CamelCase, even when
    > trying to interoperate with the C++ standard library. One striking
    > example is Andrei's book Modern C++ Design. What is the reason for
    > using CamelCase? Since static identifiers effectively define the
    > interface supported by each type, how is syntactic compatibility
    > maintained between CamelCase libraries and the snake_case STL?


    What does a naming convention have to do with syntax? As long as
    any identifier is valid and not a reserved one (which a convention
    like CamelCase would ensure), what would be the objection to using
    it?

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Mar 22, 2008
    #2
    1. Advertising

  3. Jeff Schwab

    Kai-Uwe Bux Guest

    Victor Bazarov wrote:

    > Jeff Schwab wrote:
    >> Some people who clearly understand generic programming (probably a
    >> good deal better than I do) seem to prefer CamelCase, even when
    >> trying to interoperate with the C++ standard library. One striking
    >> example is Andrei's book Modern C++ Design. What is the reason for
    >> using CamelCase? Since static identifiers effectively define the
    >> interface supported by each type, how is syntactic compatibility
    >> maintained between CamelCase libraries and the snake_case STL?

    >
    > What does a naming convention have to do with syntax? As long as
    > any identifier is valid and not a reserved one (which a convention
    > like CamelCase would ensure), what would be the objection to using
    > it?


    For instance, in your own container-like classes, would you call the
    iterators "iterator" and "const_iterator" or "Iterator"
    and "ConstIterator"? The first convention has the advantage that generic
    programs using "typename ContainerType::iterator" will work seamlessly with
    containers from STL and your own containers.


    Best

    Kai-Uwe Bux
    Kai-Uwe Bux, Mar 22, 2008
    #3
  4. Jeff Schwab

    Jeff Schwab Guest

    Victor Bazarov wrote:
    > Jeff Schwab wrote:
    >> Some people who clearly understand generic programming (probably a
    >> good deal better than I do) seem to prefer CamelCase, even when
    >> trying to interoperate with the C++ standard library. One striking
    >> example is Andrei's book Modern C++ Design. What is the reason for
    >> using CamelCase? Since static identifiers effectively define the
    >> interface supported by each type, how is syntactic compatibility
    >> maintained between CamelCase libraries and the snake_case STL?

    >
    > What does a naming convention have to do with syntax? As long as
    > any identifier is valid and not a reserved one (which a convention
    > like CamelCase would ensure), what would be the objection to using
    > it?


    Consider a naming convention that both method and type names begin with
    capital letters. You define a container:

    struct MyContainer {
    //...

    Iterator Begin();
    Iterator End();
    };

    If you have a generic function template designed to work with standard
    containers, it will expect the method names to be "begin" and "end", not
    "Begin" and "End". To the extent that the actual and expected names
    differ, the container and the function become incompatible. The same
    holds for traits types, e.g. algorithm implementations may need to know
    a container's value_type, rather than its ValueType.

    I'm not saying that any particular convention is superior to any other,
    but that generic code is only as generic as the naming conventions it
    expects. Expecting names to follow a standardized convention is no
    different (AFAICS) from expecting iterator types to support prefix
    increment and dereference operations, or otherwise associating concepts
    with syntax.
    Jeff Schwab, Mar 22, 2008
    #4
  5. Jeff Schwab

    Jim Langston Guest

    Jeff Schwab wrote:
    > Victor Bazarov wrote:
    >> Jeff Schwab wrote:
    >>> Some people who clearly understand generic programming (probably a
    >>> good deal better than I do) seem to prefer CamelCase, even when
    >>> trying to interoperate with the C++ standard library. One striking
    >>> example is Andrei's book Modern C++ Design. What is the reason for
    >>> using CamelCase? Since static identifiers effectively define the
    >>> interface supported by each type, how is syntactic compatibility
    >>> maintained between CamelCase libraries and the snake_case STL?

    >>
    >> What does a naming convention have to do with syntax? As long as
    >> any identifier is valid and not a reserved one (which a convention
    >> like CamelCase would ensure), what would be the objection to using
    >> it?

    >
    > Consider a naming convention that both method and type names begin
    > with capital letters. You define a container:
    >
    > struct MyContainer {
    > //...
    >
    > Iterator Begin();
    > Iterator End();
    > };
    >
    > If you have a generic function template designed to work with standard
    > containers, it will expect the method names to be "begin" and "end",
    > not "Begin" and "End". To the extent that the actual and expected
    > names differ, the container and the function become incompatible. The same
    > holds for traits types, e.g. algorithm implementations may
    > need to know a container's value_type, rather than its ValueType.
    >
    > I'm not saying that any particular convention is superior to any
    > other, but that generic code is only as generic as the naming
    > conventions it expects. Expecting names to follow a standardized
    > convention is no different (AFAICS) from expecting iterator types to
    > support prefix increment and dereference operations, or otherwise
    > associating concepts with syntax.


    I like CamelCase becuase it's easier to read. I don't like some of the
    suggestions such as classes starting with a capital letter, variables not or
    vice versa becuase it is to easy to simply get it wrong. Typing an E
    instead of an e for example being a hard bug to find.

    I also kinda of like the fact that the STL uses all small letters and my own
    variables and classes use CamelCase, it's fairly easy on a glance of a
    program to determine what is coming from where. But in the long run, it
    doesn't matter. Whatever your organization decides upon everyone use it. I
    don't think there really is a right way.

    The same with some classes having private variables and methods end with _
    such as MyVar_ some people like it, some people don't. If you don't like
    it, don't use it in your organization. If you do, try to get it used in
    your organization. I really don't think there is a consensus amongst C++
    programmers which is best nor do I feel there will ever be. Just be
    flexible enough to use whatever formatting your orgranization calls for.


    --
    Jim Langston
    Jim Langston, Mar 23, 2008
    #5
  6. Jeff Schwab wrote:
    > Some people who clearly understand generic programming (probably a good
    > deal better than I do) seem to prefer CamelCase, even when trying to
    > interoperate with the C++ standard library. One striking example is
    > Andrei's book Modern C++ Design. What is the reason for using
    > CamelCase?


    What is the reason of using _any_ case? The "cases" and other conventions you
    use is always matters of personal preference (unless your hands are tied by some
    coding standard). CamelCase is no worse and no better than any other case,
    regardless of what religious followers of other cases might tell you.

    Consistency is important, but when the different approaches to naming are
    clearly separated (by library boundaries, for example), they don't produce any
    problems. Or can even be beneficial.

    > Since static identifiers effectively define the interface
    > supported by each type, how is syntactic compatibility maintained
    > between CamelCase libraries and the snake_case STL?


    I don't see the problem here. What exactly do you mean by "syntactic compatibility"?

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Mar 23, 2008
    #6
  7. Jeff Schwab

    Guest

    Re: generic programming: (in?)compatibility of CamelCase andsnake_case

    On Mar 22, 2:57 pm, Jeff Schwab <> wrote:
    > Some people who clearly understandgenericprogramming (probably a good
    > deal better than I do) seem to prefer CamelCase, even when trying to
    > interoperate with the C++ standard library. One striking example is
    > Andrei's book Modern C++ Design. What is the reason for using
    > CamelCase? Since static identifiers effectively define the interface
    > supported by each type, how is syntactic compatibility maintained
    > between CamelCase libraries and the snake_case STL?


    Reasons for using either would be personal preference; but I think an
    accurate way to look at it is: use whatever you want, but be aware
    that the STL uses a specific naming convention and therefore places
    constraints on what *you* can do if you are designing for STL
    compatibility.

    The only way syntactic compatibility can be maintained between
    CamelCase libraries and snake_case STL is by not strictly adhering to
    CamelCase in the libraries -- assuming the STL is the constant factor,
    everything else has to be adjusted to maintain compatibility.

    My own *personal* preference, as far as capitalization goes, is a sort
    of variation on CamelCase with some habits I've developed -- except
    when defining types that are supposed to be compatible with the STL,
    in which case I stick to STL's naming convention, e.g.
    SomeThing::iterator.

    Really, the *only* way to maintain that kind of syntactic
    compatibility is to, well, use a compatible syntax. Of course:

    #define Iterator iterator
    <g>

    Jason
    , Mar 23, 2008
    #7
  8. On 2008-03-22 21:44, Kai-Uwe Bux wrote:
    > Victor Bazarov wrote:
    >
    >> Jeff Schwab wrote:
    >>> Some people who clearly understand generic programming (probably a
    >>> good deal better than I do) seem to prefer CamelCase, even when
    >>> trying to interoperate with the C++ standard library. One striking
    >>> example is Andrei's book Modern C++ Design. What is the reason for
    >>> using CamelCase? Since static identifiers effectively define the
    >>> interface supported by each type, how is syntactic compatibility
    >>> maintained between CamelCase libraries and the snake_case STL?

    >>
    >> What does a naming convention have to do with syntax? As long as
    >> any identifier is valid and not a reserved one (which a convention
    >> like CamelCase would ensure), what would be the objection to using
    >> it?

    >
    > For instance, in your own container-like classes, would you call the
    > iterators "iterator" and "const_iterator" or "Iterator"
    > and "ConstIterator"? The first convention has the advantage that generic
    > programs using "typename ContainerType::iterator" will work seamlessly with
    > containers from STL and your own containers.


    This is really more a question about making your class conform to a
    certain interface than anything else, you have the same problem if your
    class derives from some other class that uses some other convention. As
    for making you code work with standard library templates I think that
    the next version of the standard will have something concept maps which
    will solve this issue.

    --
    Erik Wikström
    Erik Wikström, Mar 23, 2008
    #8
  9. Jeff Schwab

    James Kanze Guest

    Re: generic programming: (in?)compatibility of CamelCase andsnake_case

    On 22 mar, 21:55, Jeff Schwab <> wrote:
    > Victor Bazarov wrote:
    > > Jeff Schwab wrote:
    > >> Some people who clearly understand generic programming (probably a
    > >> good deal better than I do) seem to prefer CamelCase, even when
    > >> trying to interoperate with the C++ standard library. One striking
    > >> example is Andrei's book Modern C++ Design. What is the reason for
    > >> using CamelCase? Since static identifiers effectively define the
    > >> interface supported by each type, how is syntactic compatibility
    > >> maintained between CamelCase libraries and the snake_case STL?


    > > What does a naming convention have to do with syntax? As long as
    > > any identifier is valid and not a reserved one (which a convention
    > > like CamelCase would ensure), what would be the objection to using
    > > it?


    > Consider a naming convention that both method and type names
    > begin with capital letters. You define a container:


    > struct MyContainer {
    > //...


    > Iterator Begin();
    > Iterator End();
    > };


    [Nothing to do with your question, but...]

    More usual would be:

    struct MyContainer
    {
    // ...
    Iterator begin() ;
    Iterator end() ;
    } ;

    One of the goals of a naming convention should be to distinguish
    typenames from all other symbols.

    > If you have a generic function template designed to work with
    > standard containers,


    If you have generic function templates designed to work with
    containers, you haven't quite caught philosophy of the standard
    library. Generic functions should be designed to work with
    iterators. Where the names of the critical functions are *, ++
    and ==; it's blatant abuse of operator overloading, but it does
    avoid any argument about naming conventions.

    > it will expect the method names to be "begin" and "end", not
    > "Begin" and "End". To the extent that the actual and expected
    > names differ, the container and the function become
    > incompatible. The same holds for traits types, e.g. algorithm
    > implementations may need to know a container's value_type,
    > rather than its ValueType.


    Certainly, when you want a name required by an external (to your
    code) element, you conform to its requirements. The standard is
    just one example; you don't call pthreadCreate, either.

    I actually find this one (very small) advantage of camel case:
    the reader knows immediately, from the way the name is formed,
    whether the intent is to conform with some external convention
    or not.

    > I'm not saying that any particular convention is superior to
    > any other, but that generic code is only as generic as the
    > naming conventions it expects. Expecting names to follow a
    > standardized convention is no different (AFAICS) from
    > expecting iterator types to support prefix increment and
    > dereference operations, or otherwise associating concepts with
    > syntax.


    Exactly. The naming convention is part of the interface.
    Without the interface requirements, you certainly wouldn't
    overload ++ for an iterator, and without the interface
    requirements, you might prefer the name ValueType, rather than
    value_type.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Mar 24, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Benson

    entering the lists against CamelCase

    John Benson, Dec 7, 2003, in forum: Python
    Replies:
    2
    Views:
    293
    John Roth
    Dec 8, 2003
  2. Mark Hahn
    Replies:
    97
    Views:
    2,150
    Martin Maney
    Apr 29, 2004
  3. minlearn
    Replies:
    2
    Views:
    442
    red floyd
    Mar 13, 2009
  4. Gavin Kistner

    Appropriate use of camelCase

    Gavin Kistner, Feb 23, 2004, in forum: Ruby
    Replies:
    3
    Views:
    156
  5. Michael Neumann

    CamelCase issues

    Michael Neumann, Oct 21, 2004, in forum: Ruby
    Replies:
    28
    Views:
    228
    Stefan Schmiedl
    Oct 23, 2004
Loading...

Share This Page