DEX wrote:
Main page of my NC:
http://www.ddmrm.com/coding/cpp/nami...ming.main.html
Rules of my NC:
http://www.ddmrm.com/coding/cpp/nami...ing.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
