Naming conventions

[Miguel Guedes]

Hello,

Does anyone have a link to the C++ Standard Library naming conventions
that they could share? I have found a few links to pages on C++ naming
conventions but am unsure as to what standard they follow.

Best Regards,

-- Miguel Guedes

- X marks the spot for spammers. If you wish to get in touch with me by
email, remove the X from my address. -

[Victor Bazarov]

Miguel Guedes wrote:

Does anyone have a link to the C++ Standard Library naming conventions
that they could share? I have found a few links to pages on C++ naming
conventions but am unsure as to what standard they follow.

What do you need it for? If you want to know what's allowed to be used,
get a copy of the Standard, and see what's not allowed; everything else
would be OK. All names visible to the programmer are defined in the
Standard already. You're not supposed to add any. If you need to know
what functions/objects/types exist, get yourself a reference manual.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Miguel Guedes]

Victor Bazarov wrote:

Miguel Guedes wrote:
What do you need it for? If you want to know what's allowed to be used,
get a copy of the Standard, and see what's not allowed; everything else
would be OK. All names visible to the programmer are defined in the
Standard already. You're not supposed to add any. If you need to know
what functions/objects/types exist, get yourself a reference manual.

V

I'm sorry for not making myself clear, Victor.

I'd like to adopt standard compliant naming conventions and thought that
the best way to do it would be to read up on the C++ standard naming
conventions. Boost.org, for instance, recommends this.

I found a link [1] but, seeing the standards presented on the page are
_derived_ from the C++ Coding Standards, I'm unsure what to make of it...
[1] http://www.nws.noaa.gov/oh/hrl/ihfs/...C++_naming.htm

--
Miguel Guedes

- X marks the spot for spammers. If you wish to get in touch with me by
email, remove the X from my address. -

[Victor Bazarov]

Miguel Guedes wrote:

Victor Bazarov wrote:

>Miguel Guedes wrote:
What do you need it for? If you want to know what's allowed to be
used, get a copy of the Standard, and see what's not allowed;
everything else would be OK. All names visible to the programmer
are defined in the Standard already. You're not supposed to add
any. If you need to know what functions/objects/types exist, get
yourself a reference manual.

V

I'm sorry for not making myself clear, Victor.

I'd like to adopt standard compliant naming conventions and thought
that the best way to do it would be to read up on the C++ standard
naming conventions. Boost.org, for instance, recommends this.

I found a link [1] but, seeing the standards presented on the page are
_derived_ from the C++ Coding Standards, I'm unsure what to make of
it...
[1] http://www.nws.noaa.gov/oh/hrl/ihfs/...C++_naming.htm

Ah... Um... All names are lowercase. Multi-word names have words
separated by underscores (random_shuffle, push_back, find_if). It's
not as consistent as many would like, though. E.g. "getline" is
a single "word", no underscores (and there are other examples like
that).

Don't get hung up on a specific naming convention. Pick one that is
convenient and be consistent with it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Miguel Guedes]

Victor Bazarov wrote:

Ah... Um... All names are lowercase. Multi-word names have words
separated by underscores (random_shuffle, push_back, find_if). It's
not as consistent as many would like, though. E.g. "getline" is
a single "word", no underscores (and there are other examples like
that).

Don't get hung up on a specific naming convention. Pick one that is
convenient and be consistent with it.

V

Trouble is I have many questions I've not been able to find convincing
answers to. For instance:

- When naming pointers should I append a prefix (pName, or p_name), add
a suffix (name_p) or nothing at all?

- Should I name namespaces in all-lowercase letters or follow class name
conventions (all words start with uppercase)?

- What about global and static variables? Should I append a prefix 'glo'
and 'sta' respectively, as the guidelines in Boost.org recommend?

I won't bore you to death. This is just an illustration of how much
unsure I am when it comes to naming conventions.

In all honesty, the reason why I started this thread was because I'm
still using remnants of Microsoft's crippled god-awful hungarian
notation (professional obligation) and want to completely get rid of all
the inconsistencies it introduces. So, seeing I'm about to start anew, I
thought that there's nothing better than to follow _proper_ standards -
the ones specified in C++ standards.
--
Miguel Guedes

- X marks the spot for spammers. If you wish to get in touch with me by
email, remove the X from my address. -

[Victor Bazarov]

Miguel Guedes wrote:

Victor Bazarov wrote:

>Ah... Um... All names are lowercase. Multi-word names have words
separated by underscores (random_shuffle, push_back, find_if). It's
not as consistent as many would like, though. E.g. "getline" is
a single "word", no underscores (and there are other examples like
that).

Don't get hung up on a specific naming convention. Pick one that is
convenient and be consistent with it.

V

Trouble is I have many questions I've not been able to find convincing
answers to. For instance:

- When naming pointers should I append a prefix (pName, or p_name),
add a suffix (name_p) or nothing at all?

- Should I name namespaces in all-lowercase letters or follow class
name conventions (all words start with uppercase)?

- What about global and static variables? Should I append a prefix
'glo' and 'sta' respectively, as the guidelines in Boost.org
recommend?

I won't bore you to death. This is just an illustration of how much
unsure I am when it comes to naming conventions.

In all honesty, the reason why I started this thread was because I'm
still using remnants of Microsoft's crippled god-awful hungarian
notation (professional obligation) and want to completely get rid of
all the inconsistencies it introduces. So, seeing I'm about to start
anew, I thought that there's nothing better than to follow _proper_
standards - the ones specified in C++ standards.

You're a bit mistaken here. The C++ Standard does NOT specify any
naming convention. It tries to follow some, but isn't doing a good
job, either.

Cleaning out inconsistencies is a good goal to have, unfortunately
it's an unattainable one. Even if you do a piece-meal by collecting
different conventions from more than one style guide, you will likely
end up with some sort of inconsistency or two. There is no escape.

The rule of thumb here is "try to be simple, as simple as possible,
but not simpler". If you think you need prefices, use them. Which
ones? Who cares? You just need to be consistent. 'p' for pointers,
'g' for globals, 'm' for members... It does not matter. The
Standard Library and the language proper does not use many prefices,
but it uses suffices, like '_t' for new types (size_t, ptrdiff_t).
Is that better? Not sure. Not all types have _t on them either.

Here is my final advice: take _a_ convention and write it down. Try
to reduce the number of rules you have in your style guide. If you
can, have no more than, say, five rules. If in the process of
following your own style guide you find that you need to introduce
more rules, try to resist the temptation becuase it may mean you'll
need to review previously written code, where you didn't follow
the same new rules. IOW, the style guide should be (a) a *guide*
not a *law*, and (b) *descriptive* more than *perscriptive*.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Gianni Mariani]

Miguel Guedes wrote:

Victor Bazarov wrote:

>Ah... Um... All names are lowercase. Multi-word names have words
separated by underscores (random_shuffle, push_back, find_if). It's
not as consistent as many would like, though. E.g. "getline" is
a single "word", no underscores (and there are other examples like
that).

Don't get hung up on a specific naming convention. Pick one that is
convenient and be consistent with it.

V

Trouble is I have many questions I've not been able to find convincing
answers to. For instance:

- When naming pointers should I append a prefix (pName, or p_name), add
a suffix (name_p) or nothing at all?

- Should I name namespaces in all-lowercase letters or follow class name
conventions (all words start with uppercase)?

- What about global and static variables? Should I append a prefix 'glo'
and 'sta' respectively, as the guidelines in Boost.org recommend?

I won't bore you to death. This is just an illustration of how much
unsure I am when it comes to naming conventions.

In all honesty, the reason why I started this thread was because I'm
still using remnants of Microsoft's crippled god-awful hungarian
notation (professional obligation) and want to completely get rid of all
the inconsistencies it introduces. So, seeing I'm about to start anew, I
thought that there's nothing better than to follow _proper_ standards -
the ones specified in C++ standards.

I have a naming convention for you.

Pick names that mean somthing useful.

e.g., I don't find it useful to prepend "p" for pointer, but I do find
it useful to prepend "s_" for static, or "w_" for template parameter or
"m_" for member variable - but not for function names.

The convention I usually use is:

When declaring function parameters do:
i_ - input
o_ - output
io_ - input/output

Class members:
t_ - type
m_ - member
s_ - static member

Templates
w_ - template parameter

Other decls
g_ - global variable
l_ - local variable
This does help me disambiguate some cases - like:

struct A
{
int m_val;
A( int i_val ) : m_val( i_val ) {}
};
Make sense ?

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-08-22 22:41, Miguel Guedes wrote:

Victor Bazarov wrote:

>Ah... Um... All names are lowercase. Multi-word names have words
separated by underscores (random_shuffle, push_back, find_if). It's
not as consistent as many would like, though. E.g. "getline" is
a single "word", no underscores (and there are other examples like
that).

Don't get hung up on a specific naming convention. Pick one that is
convenient and be consistent with it.

V

Trouble is I have many questions I've not been able to find convincing
answers to. For instance:

- When naming pointers should I append a prefix (pName, or p_name), add
a suffix (name_p) or nothing at all?

Use names that makes sense, it's often more important to know what it
points to than that it's a pointer. Most IDEs can tell you the type of a
variable but they can not tell you what the value represents.

- Should I name namespaces in all-lowercase letters or follow class name
conventions (all words start with uppercase)?

As previously pointed out, the classes etc. in the standard library use
underscores and not camel-case. Personally I like camel-case better but
Bjarne Stroustrup claims that underscores have been proven to be more
readable.

- What about global and static variables? Should I append a prefix 'glo'
and 'sta' respectively, as the guidelines in Boost.org recommend?

You should avoid globals :-)

I won't bore you to death. This is just an illustration of how much
unsure I am when it comes to naming conventions.

In all honesty, the reason why I started this thread was because I'm
still using remnants of Microsoft's crippled god-awful hungarian
notation (professional obligation) and want to completely get rid of all
the inconsistencies it introduces.

If you try to get rid of MS's Hungarian notation then why do you try to
put it back in with prefixing stuff. The original Hungarian notation
used prefixes to indicate what type of data was stored, not the type of
the variable used to store them, i.e. szWidth indicates that the
variable contains the size of something.

So, seeing I'm about to start anew, I thought that there's nothing
better than to follow _proper_ standards - the ones specified in C++
standards.

There is no formal C++ naming convention used by the standards committee
(AFAIK) but they do try to keep things consistent but I'm quite sure
that there are inconsistencies, some due to backward compatibility no
doubt. If you are looking at for a standard you'll probably have better
luck looking at Java and .Net, for frameworks that large I'm sure they
have worked out some standard.

Get something that feels comfortable and start to write a list of how
you should name stuff, when you can no longer come up with any more
cases start using the standard and fix the remaining cases as they come
up. It does not matter what standard you use, because I can almost
guarantee that none else will used the same standard, there are always
some corner cases where they differ.

--
Erik Wikström

[Bo Persson]

Gianni Mariani wrote:
:: Miguel Guedes wrote:
:::
::: In all honesty, the reason why I started this thread was because
::: I'm still using remnants of Microsoft's crippled god-awful
::: hungarian notation (professional obligation) and want to
::: completely get rid of all the inconsistencies it introduces. So,
::: seeing I'm about to start anew, I thought that there's nothing
::: better than to follow _proper_ standards - the ones specified in
::: C++ standards.
::
:: I have a naming convention for you.
::
:: Pick names that mean somthing useful.

Good idea!!

::
:: struct A
:: {
:: int m_val;
:: A( int i_val ) : m_val( i_val ) {}
:: };
::
::
:: Make sense ?

Personally I don't like all the underscores and little separate
characters.

I have a hypothesis that there might be some cultural preferences
between people using get_line() and GetLine(). Scandinavians and
germans, for example are very used to create new words by appending a
number of smaller words. We do that all the time, IRL! English and
americans do not, and that might make them prefer to write
lots_of_little_words_with_undescores. I find that hard to read!

struct A
{
int Value;
A(int Init) : Value(Init) {}
};

Bo Persson

[Bo Persson]

Miguel Guedes wrote:
:: Victor Bazarov wrote:
::: Ah... Um... All names are lowercase. Multi-word names have words
::: separated by underscores (random_shuffle, push_back, find_if).
::: It's not as consistent as many would like, though. E.g.
::: "getline" is
::: a single "word", no underscores (and there are other examples like
::: that).
:::
::: Don't get hung up on a specific naming convention. Pick one that
::: is convenient and be consistent with it.
:::
::: V
::
:: Trouble is I have many questions I've not been able to find
:: convincing answers to. For instance:
::
:: - When naming pointers should I append a prefix (pName, or
:: p_name), add a suffix (name_p) or nothing at all?

Think about what that will buy you. Is it important to always know
that something is a pointer? When you later realize that it should
have been a reference, will you change the name?

Pointers are easily recognized as they are used in expressions like
*Name, or Name->Something.

::
:: - Should I name namespaces in all-lowercase letters or follow
:: class name conventions (all words start with uppercase)?

You should probably just use one way of creating names. Otherwise you
risk getting names that just differs by case.

namespace car
{
class Car;
}

Now you have

car::Car // a type

Car::Car // a constructor

Not good!

::
:: - What about global and static variables? Should I append a prefix
:: 'glo' and 'sta' respectively, as the guidelines in Boost.org
:: recommend?

You probably shouldn't use many of these in the first place! :-)

If you need some global configuration settings, for example, you can
put them in a namespace and get code like:

if (Global::Config::ShowDebugInfo)
{
// display something interesting
}

::
:: I won't bore you to death. This is just an illustration of how much
:: unsure I am when it comes to naming conventions.

So are we. And nobody agrees anyway!

Use readable names!

::
:: In all honesty, the reason why I started this thread was because
:: I'm still using remnants of Microsoft's crippled god-awful
:: hungarian notation (professional obligation) and want to
:: completely get rid of all the inconsistencies it introduces.

That was somewhat useful once upon a time, to simulate type checking
when C types were really just typedefs. In C++ the compiler will tell
you not to mix two incompatible classes in the same expression.

:: So,
:: seeing I'm about to start anew, I thought that there's nothing
:: better than to follow _proper_ standards - the ones specified in
:: C++ standards.

And there aren't any. :-(
Bo Persson

[Miguel Guedes]

Bo Persson wrote:

>
Think about what that will buy you. Is it important to always know
that something is a pointer? When you later realize that it should
have been a reference, will you change the name?

Pointers are easily recognized as they are used in expressions like
*Name, or Name->Something.

You should probably just use one way of creating names. Otherwise you
risk getting names that just differs by case.

namespace car
{
class Car;
}

Now you have

car::Car // a type

Car::Car // a constructor

Not good!

Note taken. I asked that question because STL's namespaces are all in
lowercase and I think I read a guideline somewhere on the Net.

>
You probably shouldn't use many of these in the first place! :-)

If you need some global configuration settings, for example, you can
put them in a namespace and get code like:

if (Global::Config::ShowDebugInfo)
{
// display something interesting
}

::
:: I won't bore you to death. This is just an illustration of how much
:: unsure I am when it comes to naming conventions.

So are we. And nobody agrees anyway!

He he. Somehow I don't feel as bad!

>
Use readable names!
That was somewhat useful once upon a time, to simulate type checking
when C types were really just typedefs. In C++ the compiler will tell
you not to mix two incompatible classes in the same expression.

:: So,
:: seeing I'm about to start anew, I thought that there's nothing
:: better than to follow _proper_ standards - the ones specified in
:: C++ standards.

And there aren't any. :-(
Bo Persson

So, I take it the moral of the story is: make up your own naming
convention and stick to them?

--
Miguel Guedes

- X marks the spot for spammers. If you wish to get in touch with me by
email, remove the X from my address. -

[Frank Birbacher]

Hi!

Alf P. Steinbach schrieb:

Personally I prefer first letter uppercase (Pascal-case) for types and
having all other names in camel-case, which frees the underscore for the
places it really can help separate logically distinct name parts, and
also makes it possible to have "Bananas bananas" without being overly
creative in trying to come up with some distinct name for the instance.

Yes. I agree to this. This matches my preferences. And with Bo's
hypothesis: I'm German and I don't like names_with_underscores, but I
like CamelCase.

For a period I tended to stick a "_" suffix on template names, but I
can't recollect why I thought that was so splendid an idea.

I see them as regular types, thus they get an uppercase CamelCase name
which usually names the concept the type needs to implement:
template<typename RandomAccessIterator...

But I disagree on Bo's namespace example:

namespace car {
class Car;
}

car::Car //type
Car::Car //ctor

I use lowercase namespace names. But this ambiguty has never bitten me.
Creating a namespace with the same name as a type therein seems to be a
conceptual error in naming (at least to me).

Frank

[Frank Birbacher]

Hi!

Gianni Mariani schrieb:

In my opinion, your opinion is unfounded since I have experience
otherwise that tells me it's easy to use and makes code more readable.

How many lines of code does your average function contain?

Frank

[Frank Birbacher]

Hi!

Miguel Guedes schrieb:

Good to know it's not against any C++ programmer's standard to adopt
template type names lengthier than one letter.

Well, :) if there is no particular concept the type needs to model I
will use "T" as the template parameter (assuming value semantics, which
could be expressed as CopyConstructibleAndAssignable, but that is too
clumsy). I take this as a consensus just like using "i" as a "for"-loop
counter. But often enough I also name it "Value". I guess I'm still
searching for my personal naming convention. ;)

This newsgroup is without a doubt a source of immense knowledge.

:D

Frank

[Joe Greer]

"Bo Persson" <bo*@gmb.dkwrote in
news:5j*************@mid.individual.net:

>::
:: - When naming pointers should I append a prefix (pName, or
:: p_name), add a suffix (name_p) or nothing at all?

Think about what that will buy you. Is it important to always know
that something is a pointer? When you later realize that it should
have been a reference, will you change the name?

Pointers are easily recognized as they are used in expressions like
*Name, or Name->Something.

::

Well, personally, I think that pointerness is part of the name. :) I
always use pCar rather than car, because the variable
isn't a car it's a pointer to a car and a p is shorter that suffixing it
with ptr.

I developed my convention prior to having clever IDEs, so some of the
guidelines are there to help me find the variables. I still find it
convenient to know at a glance where things are coming from during the
maintenance phase of development, so I haven't adjusted it much.

I generally use camel case for naming items.

Variables start with a lower case letter (This rule includes any
prefixes as part of the variable name, thus car, m_Car, m_pCar, pCar etc
are all variables).

Members get prefixed with m_.

Statics are prefixed with an s_

Globals (if any) get prefixed with a g_.

Locals don't get a prefix because they should be declared nearby and are
easily found.

Functions, class names and constants start with a capital letter
(MaxSize, SomeClass).

I haven't really formed a strong preference for
namespaces. So far, I have kept them lowercase and sometimes with '_'s
instead of camel case. I suppose for consistency, I should prefer camel
case starting with a capital (like classes), but I create far fewer
namespaces than classes, so I haven't developed a strong preference.

Now for some anti patterns:

I really really don't like trailing '_'s or even prefixes because they
look horrible in actual code. Things like carptr_->engine_ just look
weird to me and so does _carptr->_engine. Just too many straight lines
in a row. But, that's just my opinion. :)

Hope that helps more than adds to the confusion.

joe

[Jorgen Grahn]

On Thu, 23 Aug 2007 00:34:16 +0200, Alf P. Steinbach <al***@start.nowrote:

* Miguel Guedes:

>>
So, I take it the moral of the story is: make up your own naming
convention and stick to them?

To some degree.

However, Java and C# have established naming conventions, and to keep
things as simple as possible it's a good idea to try to use as much as
practical of the same conventions in all three languages, e.g. [...]

Uh, some of us would hate having to conform to conventions from other,
inferior languages. Especially when we have no contact with them
whatsoever.

I feel that for C++, there may not be *one* convention, but there is
probably one in the part of the community where you live.

The Ellemtel rules used to be popular ten years ago, for example. I
cannot really recommend them today, but here they are:
http://www.doc.ic.ac.uk/lab/cplus/c++.rules/

Using myself as another example:

I like Stroustrup's books a lot (although TC++PL doesn't pretend to be
a manual of style). Also, Stroustrup comes from a Unix/C environment
and so do I. So I managed to assemble my style using bits & pieces
from TC++PL, K&R, the Unix APIs, and various bits of code I have read
and liked in the past.

This means, among other things, relatively little CamelCase and few
funny prefixes. And pragmatism.

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!

[Jorgen Grahn]

On Wed, 22 Aug 2007 21:03:33 GMT, Erik Wikström <Er***********@telia.comwrote:
....

Personally I like camel-case better but
Bjarne Stroustrup claims that underscores have been proven to be more
readable.

Where? As I recall it, TC++PL tries to stay away from those issues; I
think he mentions somewhere that the code snippets look like they do
mostly to make the text around them readable.

That said, Stroustrup spent a lot of time at Bell Labs -- the world
capital of lower-case letters ;-)

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

On 2007-08-25 11:25, Jorgen Grahn wrote:

On Wed, 22 Aug 2007 21:03:33 GMT, Erik Wikström <Er***********@telia.comwrote:
...

>Personally I like camel-case better but
Bjarne Stroustrup claims that underscores have been proven to be more
readable.

Where? As I recall it, TC++PL tries to stay away from those issues; I
think he mentions somewhere that the code snippets look like they do
mostly to make the text around them readable.

That said, Stroustrup spent a lot of time at Bell Labs -- the world
capital of lower-case letters ;-)

It was in an interview I downloaded from the net. I think the link was
posted in here some time ago.

--
Erik Wikström