[OT] Naming Conventions: Question of Style, or Library Compatibility?

Discussion in 'C++' started by bartek, Apr 5, 2004.

  1. bartek

    bartek Guest

    Hi,

    Please forgive me this rather non-technical, but somewhat related topic.
    I just have to share a particular frustration...

    Naming conventions, and their destructive power in the world of generic
    programming.

    Say, there is a project which started w/o significant use of the standard
    library, or generic programming techniques. It had followed a naming
    convention where most of names were LikeThis (classes, member/free
    functions), LikeThisType (typedefs, template type args) and local
    variable names like_this.

    Everything looks pretty well while there is rather low interdependency
    with std lib. However, the higher it is, the more names become confusing
    and the naming convention simply starts breaking apart.
    E.g. a container class should define an 'interator' instead an
    'IteratorType'. Taking it further, it should define 'begin()' and 'end
    ()' methods instead of 'Begin()' and 'End()', etc. ("is this our class or
    std? ").

    Perhaps I'm a little bit exaggerating but ... consider an application
    written using application framework X, using libraries Y and Z, where
    each of them provides some reusable constructs, and each follows a
    different naming convention.

    Theoretically, it's possible to wrap things up in a kind of "cosmetic"
    adaptors... but isn't it simply programmer's-time-being-wasted?

    *sigh*
    <conscience>
    Now, stop whining! Back to work! NOW!
    </conscience>
    bartek, Apr 5, 2004
    #1
    1. Advertising

  2. bartek wrote:
    >
    > E.g. a container class should define an 'interator' instead an
    > 'IteratorType'. Taking it further, it should define 'begin()' and 'end
    > ()' methods instead of 'Begin()' and 'End()', etc. ("is this our class or
    > std? ").


    If you are attempting to mimic the behaviors and semantics of the
    standard containers then this would be good, because it can be a drop-in
    replacement. But if your class has significantly different semantics, I
    think this could be dangerously misleading.

    In many cases, it shouldn't matter how you get an iterator. Examples:

    Function(container.begin(), container.end());
    Function(container.Begin(), container.End());
    Function(container, container + size);

    This is part of the reason for using iterators in the first place.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
    Kevin Goodsell, Apr 5, 2004
    #2
    1. Advertising

  3. Re: [OT] Naming Conventions: Question of Style, or LibraryCompatibility?

    Kevin Goodsell wrote:
    >
    > bartek wrote:
    > >
    > > E.g. a container class should define an 'interator' instead an
    > > 'IteratorType'. Taking it further, it should define 'begin()' and 'end
    > > ()' methods instead of 'Begin()' and 'End()', etc. ("is this our class or
    > > std? ").

    >
    > If you are attempting to mimic the behaviors and semantics of the
    > standard containers then this would be good, because it can be a drop-in
    > replacement.


    Or if you are parameterising on container types in other ways, e.g.
    aggregating one container by another or using it as a parameter to a
    high-level function.


    > In many cases, it shouldn't matter how you get an iterator. Examples:
    >
    > Function(container.begin(), container.end());
    > Function(container.Begin(), container.End());
    > Function(container, container + size);
    >
    > This is part of the reason for using iterators in the first place.


    But it's so good to unify the conventions for the sake of uniformity,
    provided things do behave the same. It seems to reduce the confusion
    among the teammates who have to use the containers.

    Denis
    Denis Remezov, Apr 5, 2004
    #3
  4. bartek

    bartek Guest

    Kevin Goodsell <> wrote in
    news:BF1cc.15904$:

    > bartek wrote:
    >>
    >> E.g. a container class should define an 'interator' instead an
    >> 'IteratorType'. Taking it further, it should define 'begin()' and
    >> 'end ()' methods instead of 'Begin()' and 'End()', etc. ("is this our
    >> class or std? ").

    >
    > If you are attempting to mimic the behaviors and semantics of the
    > standard containers then this would be good, because it can be a
    > drop-in replacement. But if your class has significantly different
    > semantics, I think this could be dangerously misleading.
    >
    > In many cases, it shouldn't matter how you get an iterator. Examples:
    >
    > Function(container.begin(), container.end());
    > Function(container.Begin(), container.End());
    > Function(container, container + size);
    >
    > This is part of the reason for using iterators in the first place.


    Well, yes.
    However what I particularly don't like about this, is that the same
    concepts are expressed with different notations. Especially if the
    difference is for example in one upper/lower case letter, etc.

    While the point of using a naming convention is, besides aesthetics, a
    way to provide additional hints for the programmer, the result of use of
    mixed naming conventions is a confused programmer. I don't mean to be
    obvious here. Just expressing my feelings about it.

    For example, if one decides to use std classes in interfaces of his own
    classes, which in turn don't follow std naming convention, it all ends up
    being funny.

    E.g.:
    my_items.GetData().begin()
    bartek, Apr 5, 2004
    #4
  5. Re: [OT] Naming Conventions: Question of Style, or LibraryCompatibility?

    bartek wrote:
    >
    > Denis Remezov <> wrote in
    > news::
    >
    > >
    > > But it's so good to unify the conventions for the sake of uniformity,
    > > provided things do behave the same. It seems to reduce the confusion
    > > among the teammates who have to use the containers.
    > >

    >
    > But this is so tedious! - to provide such "cosmetic" wrappers for each and
    > every entity defined by foreign libraries... It means more work either way.


    What I had in mind is to favour the conventions of the library or the codebase
    that prevails and - perhaps? - modify the other parts to conform. Often, the
    custom conventions come and go; then, in a way, _they_ are foreign. The
    standard library will stay for a while.

    Denis
    Denis Remezov, Apr 5, 2004
    #5
  6. bartek

    bartek Guest

    Re: [OT] Naming Conventions: Question of Style, or Library Compatibility?

    Denis Remezov <> wrote in
    news::

    > Kevin Goodsell wrote:
    >>
    >> bartek wrote:
    >> >
    >> > E.g. a container class should define an 'interator' instead an
    >> > 'IteratorType'. Taking it further, it should define 'begin()' and
    >> > 'end ()' methods instead of 'Begin()' and 'End()', etc. ("is this
    >> > our class or std? ").

    >>
    >> If you are attempting to mimic the behaviors and semantics of the
    >> standard containers then this would be good, because it can be a
    >> drop-in replacement.

    >
    > Or if you are parameterising on container types in other ways, e.g.
    > aggregating one container by another or using it as a parameter to a
    > high-level function.
    >
    >
    >> In many cases, it shouldn't matter how you get an iterator. Examples:
    >>
    >> Function(container.begin(), container.end());
    >> Function(container.Begin(), container.End());
    >> Function(container, container + size);
    >>
    >> This is part of the reason for using iterators in the first place.

    >
    > But it's so good to unify the conventions for the sake of uniformity,
    > provided things do behave the same. It seems to reduce the confusion
    > among the teammates who have to use the containers.
    >


    But this is so tedious! - to provide such "cosmetic" wrappers for each and
    every entity defined by foreign libraries... It means more work either way.
    bartek, Apr 5, 2004
    #6
  7. bartek

    bartek Guest

    Re: [OT] Naming Conventions: Question of Style, or Library Compatibility?

    Denis Remezov <> wrote in
    news::

    > What I had in mind is to favour the conventions of the library or the
    > codebase that prevails and - perhaps? - modify the other parts to
    > conform. Often, the custom conventions come and go; then, in a way,
    > _they_ are foreign. The standard library will stay for a while.


    I agree, though, std unfortuanately doesn't provide any notational hints.
    And I don't mean hungarian notation here. Let's keep out of extremes.
    Of course one might argue whether those hints are really helpful. It's
    mostly subjective.
    Though, when subjectivity meets formal specifications there's always
    trouble, unless something gets enforced. It's an inherent duality in all
    high level programming languages that they must be comfortable for humans
    as well as machines. (Un)fortunately us humans tend to have personal
    preferences.

    Now, I'm still whining while I should bite my tongue and get to work...

    Cheers!
    bartek, Apr 5, 2004
    #7
    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. =B=
    Replies:
    4
    Views:
    9,267
  2. Floppy Jellopy

    Namespaces and Naming conventions

    Floppy Jellopy, Jul 20, 2005, in forum: ASP .Net
    Replies:
    4
    Views:
    512
    Kevin Spencer
    Jul 21, 2005
  3. Josh  Wolf
    Replies:
    2
    Views:
    3,246
    Martin Robins
    Mar 31, 2006
  4. Roy  Assaly
    Replies:
    1
    Views:
    457
    Roy Assaly
    Apr 10, 2006
  5. Replies:
    5
    Views:
    316
    Robert Kern
    May 10, 2005
Loading...

Share This Page