Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   [OT] Naming Conventions: Question of Style, or Library Compatibility? (http://www.velocityreviews.com/forums/t282064-ot-naming-conventions-question-of-style-or-library-compatibility.html)

bartek 04-04-2004 11:58 PM

[OT] Naming Conventions: Question of Style, or Library Compatibility?
 
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>


Kevin Goodsell 04-05-2004 12:22 AM

Re: [OT] Naming Conventions: Question of Style, or Library Compatibility?
 
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.

Denis Remezov 04-05-2004 01:04 AM

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

bartek 04-05-2004 03:31 AM

Re: [OT] Naming Conventions: Question of Style, or Library Compatibility?
 
Kevin Goodsell <usenet2.spamfree.fusion@neverbox.com> wrote in
news:BF1cc.15904$lt2.15398@newsread1.news.pas.eart 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()




Denis Remezov 04-05-2004 08:57 AM

Re: [OT] Naming Conventions: Question of Style, or LibraryCompatibility?
 
bartek wrote:
>
> Denis Remezov <denis_remezovREMOVETHIS@yahoo.ca.removethis> wrote in
> news:4070B095.359391D0@yahoo.ca.removethis:
>
> >
> > 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

bartek 04-05-2004 10:23 AM

Re: [OT] Naming Conventions: Question of Style, or Library Compatibility?
 
Denis Remezov <denis_remezovREMOVETHIS@yahoo.ca.removethis> wrote in
news:4070B095.359391D0@yahoo.ca.removethis:

> 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 04-05-2004 02:38 PM

Re: [OT] Naming Conventions: Question of Style, or Library Compatibility?
 
Denis Remezov <denis_remezovREMOVETHIS@yahoo.ca.removethis> wrote in
news:40711F68.20E4E0CF@yahoo.ca.removethis:

> 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!


All times are GMT. The time now is 07:49 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.