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

[bartek]

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]

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

 

[Denis Remezov]

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]

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]

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]

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.



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]

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!