Naming convention from my point of view

[DEX]

Main page of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.main.html
Rules of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.rules.html

Comments are welcome. ...

 

[Claudio Puviani]

Main page of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.main.html
Rules of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.rules.html

Comments are welcome. ...

I had no idea someone could come up with a naming scheme that's worse than
hungarian notation. That takes skill.

Claudio Puviani

 

[bartek]

Main page of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.main.html
Rules of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.rules.html

Comments are welcome. ...

Are you a robot?

 

[Derek]

Main page of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.main.html
Rules of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.rules.html

Comments are welcome. ...

Your convention is scary. It's Hungarian notation on steroids.

Instead of:

GI_a-> F1vc_b( &Pi_c );

I would much rather see:

pConnection->receiveMessage(&localMessageBuffer);

Many C++ IDEs can tell me everything else at a glance, so
there's no need to clutter my otherwise sensible names with
obsufcated metadata that requires a decoder ring for a new
developer to even begin to grasp.

Just my $0.02.

 

[Denis Remezov]

Main page of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.main.html
Rules of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.rules.html

Comments are welcome. ...

You made me think of two things that I find quite important in
regards to naming:

0) The famous rule of uniformity.
Loosely put, things that look alike should behave alike; and
the other way around, things that look different should behave
differently. "Should" means "I expect them to".

Normally, when I say
ClassName obj;
obj.f(a+b);

I don't care about the types or constness of a and b, whether f() is
virtual or not or whether ClassName is actually the name of a class or a
typedef-specialisation of a class template, etc. I shouldn't care.
This is why any sort of a la Hungarian notation hinders me, not helps,
in understanding the code. Even "m_" for member variables is too much
and too ugly for me. One notable exception is "p_" before pointer
variable names; pointers are actually different to references in their
syntax and behaviour.

1) Name compactness or maximum of signal-to-noise ratio.
Any extra decoration that is not readily intelligible makes the name
harder to read and understand. The same goes for suffixing/postfixing
that is recongisable but superfluous. Most of it is just noise to me.
This doesn't sound like a big deal ("just ignore it"), but it is. It
takes away a huge amount of energy in the form of concentration.

Suffixing is still used for scoping in large projects, but C++ classes
and namespaces have greatly reduced the need for it.

Denis

 

[Jack Klein]

Main page of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.main.html
Rules of my NC:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.rules.html

Comments are welcome. ...

Why should we care?

But my comment is, I don't like it.

 

[Alvaro]

You made me think of two things that I find quite important in
regards to naming:

0) The famous rule of uniformity.
Loosely put, things that look alike should behave alike; and
the other way around, things that look different should behave
differently. "Should" means "I expect them to".

Normally, when I say
ClassName obj;
obj.f(a+b);

I don't care about the types or constness of a and b, whether f() is
virtual or not or whether ClassName is actually the name of a class or a
typedef-specialisation of a class template, etc. I shouldn't care.
This is why any sort of a la Hungarian notation hinders me, not helps,
in understanding the code. Even "m_" for member variables is too much
and too ugly for me. One notable exception is "p_" before pointer
variable names; pointers are actually different to references in their
syntax and behaviour.

1) Name compactness or maximum of signal-to-noise ratio.
Any extra decoration that is not readily intelligible makes the name
harder to read and understand. The same goes for suffixing/postfixing
that is recongisable but superfluous. Most of it is just noise to me.
This doesn't sound like a big deal ("just ignore it"), but it is. It
takes away a huge amount of energy in the form of concentration.

Suffixing is still used for scoping in large projects, but C++ classes
and namespaces have greatly reduced the need for it.

Denis

I agree: prefixes and suffixes make code unreadable (I hate MS-Hungarian
notation). Library prefixes are better substituted with namespaces. I don't
even use p_ before pointers.

The only convention I try to follow and find pleasing resembles that of
Java:

-Capitalized Class Names
-lowercase variables and functions
-uppercase preprocessor macros and enums

 

[DEX]

Some of answers on your question/coments are on page:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.faq.html

some are on main page:
http://www.ddmrm.com/coding/cpp/naming/cpp.naming.main.html

dex