Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > [OT] Naming Conventions: Question of Style, or Library Compatibility?

Reply
Thread Tools

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

 
 
bartek
Guest
Posts: n/a
 
      04-04-2004
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>

 
Reply With Quote
 
 
 
 
Kevin Goodsell
Guest
Posts: n/a
 
      04-05-2004
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.
 
Reply With Quote
 
 
 
 
Denis Remezov
Guest
Posts: n/a
 
      04-05-2004
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
 
Reply With Quote
 
bartek
Guest
Posts: n/a
 
      04-05-2004
Kevin Goodsell <(E-Mail Removed)> wrote in
news:BF1cc.15904$(E-Mail Removed) hlink.net:

> 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()



 
Reply With Quote
 
Denis Remezov
Guest
Posts: n/a
 
      04-05-2004
bartek wrote:
>
> Denis Remezov <(E-Mail Removed)> wrote in
> news:(E-Mail Removed):
>
> >
> > 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
 
Reply With Quote
 
bartek
Guest
Posts: n/a
 
      04-05-2004
Denis Remezov <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 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.
 
Reply With Quote
 
bartek
Guest
Posts: n/a
 
      04-05-2004
Denis Remezov <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> 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!
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
question about Boost library naming kathy C++ 1 08-10-2011 08:19 PM
Question about Boost Library naming ? kathy C++ 1 08-02-2011 03:54 PM
while executing my client program i get the exception javax.naming.LinkException: [Root exception is javax.naming.LinkException: [Root exception is javax.naming.NameNotFoundException: remaining if plz anybody know how to solve this problem then mahesh Java 0 03-08-2007 12:26 PM
Javax.naming Exception: name not found in naming service. Harman Java 1 07-28-2006 08:51 AM
Library Naming Conventions. chris.lyon@spritenote.co.uk Python 5 05-10-2005 03:48 PM



Advertisments