It seems that the most common naming convention for class instance attributes these days (from C++ books) is the trailing underscore. When did this style become the "fashion" leader? 

What member data naming convention are folks using for their C++ production software?

On 12/20/2010 1:44 PM, Marco wrote:
> It seems that the most common naming convention for class instance
> attributes these days (from C++ books) is the trailing underscore.
> When did this style become the "fashion" leader?

Probably at about the same time as it became fashionable to bash MS for 
their "Hungarian notation" and their leading 'C' for classes and 'm_' 
for members...

> What member data naming convention are folks using for their C++
> production software?

It probably varies from group to group, but I wouldn't be surprised if 
most (more than 50%) Windows folks use 'm_' prefix for member data in 
their software.

Let me ask you, though, why do you care?

V
-- 
I do not respond to top-posted replies, please don't ask

On Dec 20, 7:44=A0pm, Marco <prenom_no...@yahoo.com> wrote:
> It seems that the most common naming convention for class instance attrib=
utes these days (from C++ books)
> is the trailing underscore. When did this style become the "fashion" lead=
er?
>
> What member data naming convention are folks using for their C++ producti=
on software?

Who cares? Doesn't matter!

Goran.

P.S. member_ (gcc), m_tpMember (MS, and tp stands for "type prefix"),
FMember (Borland, "F" is for "field").

On Dec 20, 6:44 pm, Marco <prenom_no...@yahoo.com> wrote:
> It seems that the most common naming convention for class
> instance attributes these days (from C++ books) is the
> trailing underscore. When did this style become the "fashion"
> leader?

Which books?  It used to be prevelant, but I've not seen it in
a long time.

> What member data naming convention are folks using for their
> C++ production software?

The most frequent I've seen is an m_ prefix (with s_ for static
members); I've also seen my (with our for statics), and code
which doesn't use any special mark.  (In an ideal world, no
special convention should be necessary.  The name of the
variable would say enough about it that you'd just know.  In
practice, I've not seen a team where everyone was that good at
naming, however, and some convention certainly helps then.)

--
James Kanze

On Dec 20, 7:04 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:
> On 12/20/2010 1:44 PM, Marco wrote:

> > It seems that the most common naming convention for class instance
> > attributes these days (from C++ books) is the trailing underscore.
> > When did this style become the "fashion" leader?

> Probably at about the same time as it became fashionable to bash MS for
> their "Hungarian notation" and their leading 'C' for classes and 'm_'
> for members...

Neither are what I'd call Hungarian, and as far as I know, no
one has bashed Microsoft for using a leading C for MFC classes
(in the absense of namespaces when they developed them).  What
people do object to is users who put a leading C everywhere,
since that prefix does indicate that the class is in MFC.

--
James Kanze

On Dec 21, 12:19=A0pm, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 20, 7:04 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:
>
> > On 12/20/2010 1:44 PM, Marco wrote:
> > > It seems that the most common naming convention for class instance
> > > attributes these days (from C++ books) is the trailing underscore.
> > > When did this style become the "fashion" leader?
> > Probably at about the same time as it became fashionable to bash MS for
> > their "Hungarian notation" and their leading 'C' for classes and 'm_'
> > for members...
>
> Neither are what I'd call Hungarian, and as far as I know, no
> one has bashed Microsoft for using a leading C for MFC classes
> (in the absense of namespaces when they developed them). =A0What
> people do object to is users who put a leading C everywhere,
> since that prefix does indicate that the class is in MFC.

Yes, but Victor did name them as three different decorations of
MicroSoft not as same. I remember plenty of bashing against "Hungarian
notation", first it was ugly itself and while original notation was
for attributing usage of variable MS did indicate type with it.

Using leading C (of MFC) in your own classes feels like using prefixes
Q (of QT) or WX (of wxwidgets) in your own classes, but Visual Studio
code generators and wizards encourage to use C in your own classes.
That was also seriously frowned upon.

None bashing i remember about m_ prefix, but I have also picked up
that trailing underscore for private data members. MS m_ prefixed data
members were often public, I have none as rule. The best idea is
perhaps to agree it with team and to follow what was agreed. It is
cheap to statically check (and even convert between) such conventions.

Oh .... and because concurrency has gone into big fashion static data
members are quite out of fashion. These cause similar synchronization
overhead and scalability issues as all sorts of other singular state.

On 20/12/2010 18:44, Marco wrote:
> It seems that the most common naming convention for class instance attributes these days (from C++ books) is the trailing underscore. When did this style become the "fashion" leader?
>
> What member data naming convention are folks using for their C++ production software?

I use the following:

sFoo	// for static variables
iFoo	// for member variables, "i" stands for "instance"
aFoo	// for function arguments
foo	// local variables have no prefix

so a constructor for example looks like this:

foo::foo(int aWibble) : iWibble(aWibble) {}

It works quite well (I picked up from when I was a Symbian OS programmer).

/Leigh

Marco <prenom_nomus@yahoo.com> wrote:

> It seems that the most common naming convention for class instance attributes 
> these days (from C++ books) is the trailing underscore. When did this style 
> become the "fashion" leader? 
> 
> What member data naming convention are folks using for their C++ production 
> software?

I don't know about "folks," but in my last C++ shop, no special mark was 
used for member-variables. If you wanted to name a parameter the same as 
a member-variable, the parameter got a trailing underscore. For example:

class Foo {
   int bar;
public:
   void setBar(int bar_) {
      bar = bar_;
   }
};

In article <ea700875-ce06-464c-931d-339b54d07dd0@glegroupsg2000goo.googlegroups.com>
	comp.lang.c++@googlegroups.com writes:
>It seems that the most common naming convention for class instance attributes these days (from C++ books)
>is the trailing underscore. When did this style become the "fashion" leader? 
>
>What member data naming convention are folks using for their C++ production software?

I originally scoffed at any such notations.  But over time, I've
fallen in with the trailing underscore.  When I'm looking at code
that isn't fresh, it is helpful to me to see that a symbol is in
the instance, so I don't get annoyed at not being able to see the
declaration.

As for what I *see* most often, well that would be the leading
underscore.  It's like a meme or a code style virus.  I see it
everywhere and have (usually) given up on pointing out why it is
ill advised.

-- 
Drew Lawson            |  Pass the tea and sympathy
                       |    for he good old days are dead
                       |  Let's raise a toast to those
                       |    who best survived the life they led

Drew Lawson <drew@furrfu.invalid> wrote:
> I originally scoffed at any such notations.  But over time, I've
> fallen in with the trailing underscore.  When I'm looking at code
> that isn't fresh, it is helpful to me to see that a symbol is in
> the instance, so I don't get annoyed at not being able to see the
> declaration.

  The problem with a trailing underscore is that it makes code visually
more confusing (especially when the underscore is followed by other
symbols such as dots or dashes). Using a letter prefix is less confusing
(and also gives more possibilities, ie. using different letters for
different types of variables).

> As for what I *see* most often, well that would be the leading
> underscore.  It's like a meme or a code style virus.  I see it
> everywhere and have (usually) given up on pointing out why it is
> ill advised.

  Should suffice to say that the C++ standard frowns on the programmer
using it (IIRC).

On Dec 21, 12:33 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
> On Dec 21, 12:19 pm, James Kanze <james.ka...@gmail.com> wrote:

> > On Dec 20, 7:04 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:

> Oh .... and because concurrency has gone into big fashion static data
> members are quite out of fashion. These cause similar synchronization
> overhead and scalability issues as all sorts of other singular state.

Really.  Everyone I know still prefers "static int const size
=3D 42;" over "#define SIZE 42".  (In other words, there's static,
and there's static.)

--
James Kanze

On Dec 20, 1:44=A0pm, Marco <prenom_no...@yahoo.com> wrote:
[snip]
> What member data naming convention are folks
> using for their C++ production software?

Naming conventions are only important when you
are in a team. In that case, you should get
together with your team and decide what to do.
It's important to keep the team as happy as
can be easily achieved. If a trivial thing
like agreeing on a naming convention will
decrease arguments, I say go for it.

Personally, I can deal with just about any
sensible naming convention. The only things
I will object to are things that interfere
with standard library or compiler convnetions.
If a thing created by the development team
(variable, object, function, class, namespace,
etc. and so on) *looks* like it is one of the
things that "comes with" the compiler, then
I object that it is confusing.

But beyond that, hey. We have good text editors
built into most development environments. I can
deal with a naming convention.
Socks

Juha Nieminen <nospam@thanks.invalid> writes:
>> As for what I *see* most often, well that would be the leading
>> underscore.  It's like a meme or a code style virus.  I see it
>> everywhere and have (usually) given up on pointing out why it is
>> ill advised.
>
>   Should suffice to say that the C++ standard frowns on the programmer
> using it (IIRC).

Does it?

My vague understanding:

  + Names that contain a double underscore (__foo, foo__bar) or begin
    with an underscore followed by a capital letter (_Foo), are always
    reserved for compiler/system use

  + Any name in the global namespace with a leading underscore is
    reserved for compiler/system use

It seems fine to use names with leading underscore for class members
or local variables though.

-Miles

-- 
We have met the enemy, and he is us.  -- Pogo

Miles Bader wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
>>> As for what I *see* most often, well that would be the leading
>>> underscore.  It's like a meme or a code style virus.  I see it
>>> everywhere and have (usually) given up on pointing out why it is
>>> ill advised.
>>
>>   Should suffice to say that the C++ standard frowns on the
>> programmer using it (IIRC).
>
> Does it?
>
> My vague understanding:
>
>  + Names that contain a double underscore (__foo, foo__bar) or begin
>    with an underscore followed by a capital letter (_Foo), are
>    always reserved for compiler/system use
>
>  + Any name in the global namespace with a leading underscore is
>    reserved for compiler/system use
>
> It seems fine to use names with leading underscore for class members
> or local variables though.
>

It's technically allowed, but perhaps not "fine".

Seeing a leading underscore would make me think "implementation 
specific name in the global namespace". Isn't that adding to the 
confusion, rather than reducing it?


Bo Persson

On 12/22/2010 2:14 AM, Bo Persson wrote:
> Miles Bader wrote:
>> Juha Nieminen<nospam@thanks.invalid>  writes:
>>>> As for what I *see* most often, well that would be the leading
>>>> underscore.  It's like a meme or a code style virus.  I see it
>>>> everywhere and have (usually) given up on pointing out why it is
>>>> ill advised.
>>>
>>>    Should suffice to say that the C++ standard frowns on the
>>> programmer using it (IIRC).
>>
>> Does it?
>>
>> My vague understanding:
>>
>>   + Names that contain a double underscore (__foo, foo__bar) or begin
>>     with an underscore followed by a capital letter (_Foo), are
>>     always reserved for compiler/system use
>>
>>   + Any name in the global namespace with a leading underscore is
>>     reserved for compiler/system use
>>
>> It seems fine to use names with leading underscore for class members
>> or local variables though.
>>
>
> It's technically allowed, but perhaps not "fine".
>
> Seeing a leading underscore would make me think "implementation
> specific name in the global namespace". Isn't that adding to the
> confusion, rather than reducing it?
>
>
> Bo Persson
>
>

    As for me I found using leading underscore on class data-members 
(which i presume to be always private) very useful, because it helps 
distinguis globals (if you have them) and local vars from data-members. 
Another techniques i found either tedious like m_ (more switches) or not 
clear like iMember, where i could stands for integer or instance.

    Also i haven't yet fallen into ambiguity with implementation 
specific names, probably because they are in global namespace scope.

    It would be interesting if would be any way to force using this on 
some members. I don't know how to get such effet in current c++ but it 
could be interesting for example to allow 'explicit' word on 
data-members so they will be needed to be explicitly pointed by this.

Ex.

class Foo {
     int im_member; // implicit
     explicit int ex_member; // explicit
public:
     void bar()
     {
          im_member = 0; // ok.
          this->ex_member = 0; // ok.
	 ex_member = 0; // compilation error.
     }
};

BR, RM

On Dec 21, 9:51=A0pm, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 21, 12:33 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
>
> > On Dec 21, 12:19 pm, James Kanze <james.ka...@gmail.com> wrote:
> > > On Dec 20, 7:04 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:
> > Oh .... and because concurrency has gone into big fashion static data
> > members are quite out of fashion. These cause similar synchronization
> > overhead and scalability issues as all sorts of other singular state.
>
> Really. =A0Everyone I know still prefers "static int const size
> =3D 42;" over "#define SIZE 42". =A0(In other words, there's static,
> and there's static.)

Yes, me too. However when it is an integral constant then i usually
use naming convention of integral constants, not static members. I
prefer PascalCase for integral constants. I use PascalCase with types
too; it is rare when reader does not get if it is integral constant or
type.

With my remark i meant mutable singular state that is causing
headaches and so is better to hide as implementation detail. Hidden
details are simpler to replace when they turn into some scalability or
synchronization bottle-necks. I lack special naming convention for
static data members since i want to get rid of them.

On 12/20/2010 11:44 AM, Marco wrote:
> It seems that the most common naming convention for class instance attributes these days (from C++ books) is the trailing underscore. When did this style become the "fashion" leader?
>
> What member data naming convention are folks using for their C++ production software?



for classes:

CamelCase, usually public methods (or properties in C# or similar);
camelCase, usually fields or private methods (except in Java, where this 
is often the case for methods in general).

"z_" or "Z_" usually a "don't use" prefix (means this name is internal, 
so avoid using even if public, as it is probably public due to technical 
reasons...).

I usually don't distinguish between static/non-static fields or methods 
(hadn't thought of it).

CamelCase is also used for class names, and ICamelCase often for 
interfaces (or abstract base classes).


I may use:
something_subname

for fields or methods if there are a bit too many, or they are unrelated 
or are a single conceptual unit.

sometimes a suffix such as "_f" is used for function pointers and similar...


in C and for top-level functions (I don't often use namespaces, as they 
clash with my auto-header tools):

LIBRARY_CapsFirst, internal functions, library-specific;
LIBRARY_Component_CapsFirst, internal functions, component specific.

generally, it is ill-advised to use functions with the above naming 
(they are internal APIs).

library_alllowercase
library_component_alllowercase
library_camelCase
....

is usually used for top-level variables (generally to be avoided if 
possible) and also for library utility functions or often static-inline 
functions. sometimes with the above, special suffixes such as "_r" or 
similar are used to indicate special behavior ("_r" is typically a 
recursive function).

I don't use public global variables, as this is nasty, so all shared 
globals either need to be imported explicitly, or more typically 
accessed via API calls...


libCamelCase, is typical for public API functions.


or such...

On Dec 21, 10:16=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 20, 6:44 pm, Marco <prenom_no...@yahoo.com> wrote:
>
> > It seems that the most common naming convention for class
> > instance attributes these days (from C++ books) is the
> > trailing underscore. When did this style become the "fashion"
> > leader?
>
> Which books? =A0It used to be prevelant, but I've not seen it in
> a long time.
>
> > What member data naming convention are folks using for their
> > C++ production software?
>
> The most frequent I've seen is an m_ prefix (with s_ for static
> members); I've also seen my (with our for statics), and code
> which doesn't use any special mark. =A0(In an ideal world, no
> special convention should be necessary.


how about constructors?

class Thing
{
private:
     int i_;

public:
     Thing(int i): i_(i)
     {}
};

I need different names for the parameter and the member variable.

> The name of the
> variable would say enough about it that you'd just know. =A0In
> practice, I've not seen a team where [not?] everyone was that good at
> naming, however, and some convention certainly helps then.)

On 12/30/10 08:42 PM, Nick Keighley wrote:
> On Dec 21, 10:16 am, James Kanze<james.ka...@gmail.com>  wrote:
>> On Dec 20, 6:44 pm, Marco<prenom_no...@yahoo.com>  wrote:
>>
>>> It seems that the most common naming convention for class
>>> instance attributes these days (from C++ books) is the
>>> trailing underscore. When did this style become the "fashion"
>>> leader?
>>
>> Which books?  It used to be prevelant, but I've not seen it in
>> a long time.
>>
>>> What member data naming convention are folks using for their
>>> C++ production software?
>>
>> The most frequent I've seen is an m_ prefix (with s_ for static
>> members); I've also seen my (with our for statics), and code
>> which doesn't use any special mark.  (In an ideal world, no
>> special convention should be necessary.
>
> how about constructors?
>
> class Thing
> {
> private:
>       int i_;
>
> public:
>       Thing(int i): i_(i)
>       {}
> };
>
> I need different names for the parameter and the member variable.

That example is the classic case where you don't!

The ambiguity arises when you use the member variable in the constructor 
body.

-- 
Ian Collins

On Dec 21, 12:46=A0pm, "Daniel T." <danie...@earthlink.net> wrote:
> Marco <prenom_no...@yahoo.com> wrote:
> > It seems that the most common naming convention for class instance attr=
ibutes
> > these days (from C++ books) is the trailing underscore. When did this s=
tyle
> > become the "fashion" leader?
>
> > What member data naming convention are folks using for their C++ produc=
tion
> > software?
>
> I don't know about "folks," but in my last C++ shop, no special mark was
> used for member-variables. If you wanted to name a parameter the same as
> a member-variable, the parameter got a trailing underscore. For example:
>
> class Foo {
> =A0 =A0int bar;
> public:
> =A0 =A0void setBar(int bar_) {
> =A0 =A0 =A0 bar =3D bar_;
> =A0 =A0}
> };


I've always preferred the header file stuff to be "clean" and easily
readable so I'd rather mark the definition rather than the
declaration.

Though I tend to reverse this for POD-like structs

struct Stuff
{
    T first;
    T second;
};

Which is kind of consistent as first and second are visible to the
client

On Dec 21, 7:04=A0pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Drew Lawson <d...@furrfu.invalid> wrote:
> > I originally scoffed at any such notations. =A0But over time, I've
> > fallen in with the trailing underscore. =A0When I'm looking at code
> > that isn't fresh, it is helpful to me to see that a symbol is in
> > the instance, so I don't get annoyed at not being able to see the
> > declaration.
>
> =A0 The problem with a trailing underscore is that it makes code visually
> more confusing (especially when the underscore is followed by other
> symbols such as dots or dashes). Using a letter prefix is less confusing
> (and also gives more possibilities, ie. using different letters for
> different types of variables).

guk! And this leads to the hungarian madness!

> > As for what I *see* most often, well that would be the leading
> > underscore. =A0It's like a meme or a code style virus. =A0I see it
> > everywhere and have (usually) given up on pointing out why it is
> > ill advised.
>
> =A0 Should suffice to say that the C++ standard frowns on the programmer
> using it (IIRC).

On Dec 30, 7:42 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Dec 21, 10:16 am, James Kanze <james.ka...@gmail.com> wrote:
> > On Dec 20, 6:44 pm, Marco <prenom_no...@yahoo.com> wrote:

> > > It seems that the most common naming convention for class
> > > instance attributes these days (from C++ books) is the
> > > trailing underscore. When did this style become the "fashion"
> > > leader?

> > Which books?  It used to be prevelant, but I've not seen it in
> > a long time.

> > > What member data naming convention are folks using for their
> > > C++ production software?

> > The most frequent I've seen is an m_ prefix (with s_ for static
> > members); I've also seen my (with our for statics), and code
> > which doesn't use any special mark.  (In an ideal world, no
> > special convention should be necessary.

> how about constructors?

> class Thing
> {
> private:
>      int i_;

> public:
>      Thing(int i): i_(i)
>      {}
> };

> I need different names for the parameter and the member variable.

    class Thing
    {
    private:
        int i;
    public:
        Thing(int initialI) : i(initialI) {}
    };

If you're sufficiently explicit with your naming convention,
there should never be any need for a special convention.  The
global convention would be an unqualified substantive for types,
and a qualified substantive for variables, so the member might
be "currentState", and the parameter "initialState" (ctor) or
"newState" (mutator functions).

In practice, I've yet to encounter anyone who was systematically
sufficiently explicit, and the special convention does prove
convenient.  But I recognize that it is only because we are
human, and not perfect (at naming, in this case).

--
James Kanze

On 30/12/2010 10:43, James Kanze wrote:
> On Dec 30, 7:42 am, Nick Keighley<nick_keighley_nos...@hotmail.com>
> wrote:
>> On Dec 21, 10:16 am, James Kanze<james.ka...@gmail.com>  wrote:
>>> On Dec 20, 6:44 pm, Marco<prenom_no...@yahoo.com>  wrote:
>
>>>> It seems that the most common naming convention for class
>>>> instance attributes these days (from C++ books) is the
>>>> trailing underscore. When did this style become the "fashion"
>>>> leader?
>
>>> Which books?  It used to be prevelant, but I've not seen it in
>>> a long time.
>
>>>> What member data naming convention are folks using for their
>>>> C++ production software?
>
>>> The most frequent I've seen is an m_ prefix (with s_ for static
>>> members); I've also seen my (with our for statics), and code
>>> which doesn't use any special mark.  (In an ideal world, no
>>> special convention should be necessary.
>
>> how about constructors?
>
>> class Thing
>> {
>> private:
>>       int i_;
>
>> public:
>>       Thing(int i): i_(i)
>>       {}
>> };
>
>> I need different names for the parameter and the member variable.
>
>      class Thing
>      {
>      private:
>          int i;
>      public:
>          Thing(int initialI) : i(initialI) {}
>      };
>
> If you're sufficiently explicit with your naming convention,
> there should never be any need for a special convention.  The
> global convention would be an unqualified substantive for types,
> and a qualified substantive for variables, so the member might
> be "currentState", and the parameter "initialState" (ctor) or
> "newState" (mutator functions).
>
> In practice, I've yet to encounter anyone who was systematically
> sufficiently explicit, and the special convention does prove
> convenient.  But I recognize that it is only because we are
> human, and not perfect (at naming, in this case).
>

I am "systematically explicit" if you care to look at my reply 
else-thread.  I am sure there are plenty of other people who are 
"systematically explicit" also; after all the convention I use is lifted 
from Symbian OS guidelines.

/Leigh

On 30/12/2010 12:39, Leigh Johnston wrote:
> On 30/12/2010 10:43, James Kanze wrote:
>> On Dec 30, 7:42 am, Nick Keighley<nick_keighley_nos...@hotmail.com>
>> wrote:
>>> On Dec 21, 10:16 am, James Kanze<james.ka...@gmail.com> wrote:
>>>> On Dec 20, 6:44 pm, Marco<prenom_no...@yahoo.com> wrote:
>>
>>>>> It seems that the most common naming convention for class
>>>>> instance attributes these days (from C++ books) is the
>>>>> trailing underscore. When did this style become the "fashion"
>>>>> leader?
>>
>>>> Which books? It used to be prevelant, but I've not seen it in
>>>> a long time.
>>
>>>>> What member data naming convention are folks using for their
>>>>> C++ production software?
>>
>>>> The most frequent I've seen is an m_ prefix (with s_ for static
>>>> members); I've also seen my (with our for statics), and code
>>>> which doesn't use any special mark. (In an ideal world, no
>>>> special convention should be necessary.
>>
>>> how about constructors?
>>
>>> class Thing
>>> {
>>> private:
>>> int i_;
>>
>>> public:
>>> Thing(int i): i_(i)
>>> {}
>>> };
>>
>>> I need different names for the parameter and the member variable.
>>
>> class Thing
>> {
>> private:
>> int i;
>> public:
>> Thing(int initialI) : i(initialI) {}
>> };
>>
>> If you're sufficiently explicit with your naming convention,
>> there should never be any need for a special convention. The
>> global convention would be an unqualified substantive for types,
>> and a qualified substantive for variables, so the member might
>> be "currentState", and the parameter "initialState" (ctor) or
>> "newState" (mutator functions).
>>
>> In practice, I've yet to encounter anyone who was systematically
>> sufficiently explicit, and the special convention does prove
>> convenient. But I recognize that it is only because we are
>> human, and not perfect (at naming, in this case).
>>
>
> I am "systematically explicit" if you care to look at my reply
> else-thread. I am sure there are plenty of other people who are
> "systematically explicit" also; after all the convention I use is lifted
> from Symbian OS guidelines.
>

Actually you are talking about something slightly different; the 
convention I use differentiates between static variables, member 
variables, function parameters and local variables; this is not 
Hungarian (type) notation but "context notation".

/Leigh

Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
>> � The problem with a trailing underscore is that it makes code visually
>> more confusing (especially when the underscore is followed by other
>> symbols such as dots or dashes). Using a letter prefix is less confusing
>> (and also gives more possibilities, ie. using different letters for
>> different types of variables).
> 
> guk! And this leads to the hungarian madness!

  How does using the 'm' prefix (as opposed to the '_' prefix) "lead to
hungarian madness"?

On Dec 30, 11:08=A0pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> >> The problem with a trailing underscore is that it makes code visually
> >> more confusing (especially when the underscore is followed by other
> >> symbols such as dots or dashes). Using a letter prefix is less confusi=
ng
> >> (and also gives more possibilities, ie. using different letters for
> >> different types of variables).
>
> > guk! And this leads to the hungarian madness!
>
> =A0 How does using the 'm' prefix (as opposed to the '_' prefix) "lead to
> hungarian madness"?

Opposed to underscore suffix. Nothing leads to madness. Usually the
discussions of code style conventions ... just turn into such
emotional "ugly", "confusing", "mad", etc. madness. In practice worst
is lack of consistency. So when gathering team then it is best to
argue, vote and write it down as policy. Whatever strange it is ... if
used consistently the code base feels more uniform.

"Bo Persson" <bop@gmb.dk> writes:
>> It seems fine to use names with leading underscore for class members
>> or local variables though.
>
> It's technically allowed, but perhaps not "fine".

By "fine", I just meant that there's no language/standards issue with
such usage.

> Seeing a leading underscore would make me think "implementation 
> specific name in the global namespace". Isn't that adding to the 
> confusion, rather than reducing it?

I dunno.  In most code, uses of _actual_ single-underscore-prefixed
"implementation specific names in the global namespace" names seems to
be vanishingly rare, so I'm not sure there's a whole lot of chance for
such confusion to happen in practice (and "in practice" is the
relevant measure here, as obviously it's OK from a pedantic point of
view).

The cases where it does happen seem to be a few well-known
grandfathered-in-from-the-distant-past names, and are almost all
functions rather than variables (e.g., _exit), which makes even them
unlikely to be confused with member variables.

[Note that I'm talking from a gcc/linux perspective; it may be that
things are different in an e.g. ms-windows environment.]

-Miles

-- 
Yossarian was moved very deeply by the absolute simplicity of
this clause of Catch-22 and let out a respectful whistle.
"That's some catch, that Catch-22," he observed.
"It's the best there is," Doc Daneeka agreed.

On Dec 21, 6:44=A0am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 20/12/2010 18:44, Marco wrote:
>
> > It seems that the most common naming convention for class instance attr=
ibutes these days (from C++ books) is the trailing underscore. When did thi=
s style become the "fashion" leader?
>
> > What member data naming convention are folks using for their C++ produc=
tion software?
>
> I use the following:
>
> sFoo =A0 =A0// for static variables
> iFoo =A0 =A0// for member variables, "i" stands for "instance"

Taligent used fMemberName -- I think the f was short for field.

> aFoo =A0 =A0// for function arguments
> foo =A0 =A0 // local variables have no prefix

In another recent thread on this topic someone suggested
not putting "warts" on member names but on local variables
since their scope is more limited.  I don't have much firm
conviction on this, but think some variation of it is
helpful.  I'm experimenting with not adding any distinguishing
characters to class members at this point.


Brian Wood
Ebenezer Enterprises
http://webEbenezer.net

On Thu, 2010-12-30, Ian Collins wrote:
> On 12/30/10 08:42 PM, Nick Keighley wrote:

....
>> class Thing
>> {
>> private:
>>       int i_;
>>
>> public:
>>       Thing(int i): i_(i)
>>       {}
>> };
>>
>> I need different names for the parameter and the member variable.
>
> That example is the classic case where you don't!
>
> The ambiguity arises when you use the member variable in the constructor 
> body.

That surprises me -- are you really sure, and do you have a reference
handy?  I'm not sure you can find it out TC++PL (which is all the
literature I own).

No, don't bother -- a test with gcc makes it clear what's going on.

   foo.cc: In constructor 'Foo::Foo(int, int)':
   foo.cc:4: error: class 'Foo' does not have any field named 'b'

The i_ in 'Thing(int i): i_(i)' really *does* have to refer to a
member of Thing. It's clearly not just any lvalue, as I guess I
believed.

This is really good news -- I'm frequently annoyed when I have to come
up with unnatural names.  Normally I use the foo_ convention for
members so it's not a problem. I don't for struct-like types where all
members are public however, so either I come up with alternate
spellings or abbreviations, or I invert my own rule and use the _
suffix for the parameter name instead.

I will think of this tip as a slightly delayed Christmas gift :-)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

On Tue, 2010-12-21, James Kanze wrote:
> On Dec 20, 6:44 pm, Marco <prenom_no...@yahoo.com> wrote:
>> It seems that the most common naming convention for class
>> instance attributes these days (from C++ books) is the
>> trailing underscore. When did this style become the "fashion"
>> leader?
>
> Which books?  It used to be prevelant, but I've not seen it in
> a long time.

IIRC, it's one of two styles mentioned in

%A Trevor Misfeldt
%A Gregory Bumgardner
%A Andrew Gray
%T The elements of C++ style
%I Cambridge University Press
%D 2004

which also says a lot of things I disagree with, but at least it's
recent.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

On Dec 31, 6:07 am, Ebenezer <woodbria...@gmail.com> wrote:
> On Dec 21, 6:44 am, Leigh Johnston <le...@i42.co.uk> wrote:

> > On 20/12/2010 18:44, Marco wrote:

> > > It seems that the most common naming convention for class
> > > instance attributes these days (from C++ books) is the
> > > trailing underscore. When did this style become the
> > > "fashion" leader?

> > > What member data naming convention are folks using for
> > > their C++ production software?

> > I use the following:

> > sFoo    // for static variables
> > iFoo    // for member variables, "i" stands for "instance"

> Taligent used fMemberName -- I think the f was short for field.

> > aFoo    // for function arguments
> > foo     // local variables have no prefix

> In another recent thread on this topic someone suggested
> not putting "warts" on member names but on local variables
> since their scope is more limited.

This goes against another rule I've heard: the length of
a variable name should be inversely proportional to its scope.
I regularly use names like i and j for loop indexes (and I'd
definitely not want to prefex them), but no where else.

--
James Kanze

On 31/12/2010 08:54, James Kanze wrote:
> On Dec 31, 6:07 am, Ebenezer<woodbria...@gmail.com>  wrote:
>> On Dec 21, 6:44 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>
>>> On 20/12/2010 18:44, Marco wrote:
>
>>>> It seems that the most common naming convention for class
>>>> instance attributes these days (from C++ books) is the
>>>> trailing underscore. When did this style become the
>>>> "fashion" leader?
>
>>>> What member data naming convention are folks using for
>>>> their C++ production software?
>
>>> I use the following:
>
>>> sFoo    // for static variables
>>> iFoo    // for member variables, "i" stands for "instance"
>
>> Taligent used fMemberName -- I think the f was short for field.
>
>>> aFoo    // for function arguments
>>> foo     // local variables have no prefix
>
>> In another recent thread on this topic someone suggested
>> not putting "warts" on member names but on local variables
>> since their scope is more limited.
>
> This goes against another rule I've heard: the length of
> a variable name should be inversely proportional to its scope.
> I regularly use names like i and j for loop indexes (and I'd
> definitely not want to prefex them), but no where else.
>

Yet another bullshit rule Mr Kanze.  Just because "i" is acceptable as a 
local variable name (for loop index) does not suddenly make the 
generalization that "variable name should be inversely proportional to 
its scope" valid.

struct point
{
	int x;
	int y;
};

/Leigh

On Dec 31, 2:54=A0am, James Kanze <james.ka...@gmail.com> wrote:
> On Dec 31, 6:07 am, Ebenezer <woodbria...@gmail.com> wrote:
>
>
>
>
>
> > On Dec 21, 6:44 am, Leigh Johnston <le...@i42.co.uk> wrote:
> > > On 20/12/2010 18:44, Marco wrote:
> > > > It seems that the most common naming convention for class
> > > > instance attributes these days (from C++ books) is the
> > > > trailing underscore. When did this style become the
> > > > "fashion" leader?
> > > > What member data naming convention are folks using for
> > > > their C++ production software?
> > > I use the following:
> > > sFoo =A0 =A0// for static variables
> > > iFoo =A0 =A0// for member variables, "i" stands for "instance"
> > Taligent used fMemberName -- I think the f was short for field.
> > > aFoo =A0 =A0// for function arguments
> > > foo =A0 =A0 // local variables have no prefix
> > In another recent thread on this topic someone suggested
> > not putting "warts" on member names but on local variables
> > since their scope is more limited.
>
> This goes against another rule I've heard: the length of
> a variable name should be inversely proportional to its scope.
> I regularly use names like i and j for loop indexes (and I'd
> definitely not want to prefex them), but no where else.
>

Jeff Schwab and others have suggested using ii and jj rather
than just i and j.  I think that's partly to make variables
easier to pick up.  Adding a one character prefix to a one or
two character variable gives a length of two or three.  I'm
just trying it out at this point.

Do any impose upper limits for variable lengths?

On 31/12/2010 16:24, Ebenezer wrote:
> On Dec 31, 2:54 am, James Kanze<james.ka...@gmail.com>  wrote:
>> On Dec 31, 6:07 am, Ebenezer<woodbria...@gmail.com>  wrote:
>>
>>
>>
>>
>>
>>> On Dec 21, 6:44 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>>>> On 20/12/2010 18:44, Marco wrote:
>>>>> It seems that the most common naming convention for class
>>>>> instance attributes these days (from C++ books) is the
>>>>> trailing underscore. When did this style become the
>>>>> "fashion" leader?
>>>>> What member data naming convention are folks using for
>>>>> their C++ production software?
>>>> I use the following:
>>>> sFoo    // for static variables
>>>> iFoo    // for member variables, "i" stands for "instance"
>>> Taligent used fMemberName -- I think the f was short for field.
>>>> aFoo    // for function arguments
>>>> foo     // local variables have no prefix
>>> In another recent thread on this topic someone suggested
>>> not putting "warts" on member names but on local variables
>>> since their scope is more limited.
>>
>> This goes against another rule I've heard: the length of
>> a variable name should be inversely proportional to its scope.
>> I regularly use names like i and j for loop indexes (and I'd
>> definitely not want to prefex them), but no where else.
>>
>
> Jeff Schwab and others have suggested using ii and jj rather
> than just i and j.  I think that's partly to make variables
> easier to pick up.  Adding a one character prefix to a one or
> two character variable gives a length of two or three.  I'm
> just trying it out at this point.
>
> Do any impose upper limits for variable lengths?

You are trolling.  The number of characters in a variable name is an 
irrelevant metric; what is important is to have a meaningful variable 
name which has nothing to do with the number of characters modulo any 
coding standard requirement to have a prefix.

A compiler may impose an upper limit on symbol name length.

/Leigh

On Dec 31, 10:35=A0am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 31/12/2010 16:24, Ebenezer wrote:
>
>
>
> > On Dec 31, 2:54 am, James Kanze<james.ka...@gmail.com> =A0wrote:
> >> On Dec 31, 6:07 am, Ebenezer<woodbria...@gmail.com> =A0wrote:
>
> >>> On Dec 21, 6:44 am, Leigh Johnston<le...@i42.co.uk> =A0wrote:
> >>>> On 20/12/2010 18:44, Marco wrote:
> >>>>> It seems that the most common naming convention for class
> >>>>> instance attributes these days (from C++ books) is the
> >>>>> trailing underscore. When did this style become the
> >>>>> "fashion" leader?
> >>>>> What member data naming convention are folks using for
> >>>>> their C++ production software?
> >>>> I use the following:
> >>>> sFoo =A0 =A0// for static variables
> >>>> iFoo =A0 =A0// for member variables, "i" stands for "instance"
> >>> Taligent used fMemberName -- I think the f was short for field.
> >>>> aFoo =A0 =A0// for function arguments
> >>>> foo =A0 =A0 // local variables have no prefix
> >>> In another recent thread on this topic someone suggested
> >>> not putting "warts" on member names but on local variables
> >>> since their scope is more limited.
>
> >> This goes against another rule I've heard: the length of
> >> a variable name should be inversely proportional to its scope.
> >> I regularly use names like i and j for loop indexes (and I'd
> >> definitely not want to prefex them), but no where else.
>
> > Jeff Schwab and others have suggested using ii and jj rather
> > than just i and j. =A0I think that's partly to make variables
> > easier to pick up. =A0Adding a one character prefix to a one or
> > two character variable gives a length of two or three. =A0I'm
> > just trying it out at this point.
>
> > Do any impose upper limits for variable lengths?
>
> You are trolling. =A0The number of characters in a variable name is an
> irrelevant metric; what is important is to have a meaningful variable
> name which has nothing to do with the number of characters modulo any
> coding standard requirement to have a prefix.
>
> A compiler may impose an upper limit on symbol name length.
>

In addition to meaningful names, I would list conciseness as a
priority.  I speculate that a limit of 40 characters is helpful.

On Dec 21 2010, 7:44=C2=AC=E2=80=A0am, Leigh Johnston <le...@i42.co.uk> wro=
te:
> On 20/12/2010 18:44, Marco wrote:
>
> > It seems that the most common naming convention for class instance attr=
ibutes these days (from C++ books) is the trailing underscore. When did thi=
s style become the "fashion" leader?
>
> > What member data naming convention are folks using for their C++ produc=
tion software?
>
> I use the following:
>
> sFoo =C2=AC=E2=80=A0 =C2=AC=E2=80=A0// for static variables
> iFoo =C2=AC=E2=80=A0 =C2=AC=E2=80=A0// for member variables, "i" stands f=
or "instance"
> aFoo =C2=AC=E2=80=A0 =C2=AC=E2=80=A0// for function arguments
> foo =C2=AC=E2=80=A0 =C2=AC=E2=80=A0 // local variables have no prefix
>
> so a constructor for example looks like this:
>
> foo::foo(int aWibble) : iWibble(aWibble) {}
>
> It works quite well (I picked up from when I was a Symbian OS programmer)=
..

Seems like a nice convention, the one exception being the 'i'.
For me 'm' is better since it is already quite commonly used as
a member prefix, it connotes "me" or "my", and 'i' (paired with
'e') is nice for local iterator pairs. So maybe:

   sFoo   // for static variables
   mFoo   // for member variables
   aFoo   // for function arguments
   foo    // local variables have no prefix
   iFoo   // iterator to foo range
   eFoo   // end iterator of foo range

?

Personally, I do find some prefix convention helpful (and more
so than a suffix convention).

KHD

On 02/01/2011 02:03, Keith H Duggar wrote:
> On Dec 21 2010, 7:44 am, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 20/12/2010 18:44, Marco wrote:
>>
>>> It seems that the most common naming convention for class instance attributes these days (from C++ books) is the trailing underscore. When did this style become the "fashion" leader?
>>
>>> What member data naming convention are folks using for their C++ production software?
>>
>> I use the following:
>>
>> sFoo    // for static variables
>> iFoo    // for member variables, "i" stands for "instance"
>> aFoo    // for function arguments
>> foo     // local variables have no prefix
>>
>> so a constructor for example looks like this:
>>
>> foo::foo(int aWibble) : iWibble(aWibble) {}
>>
>> It works quite well (I picked up from when I was a Symbian OS programmer).
>
> Seems like a nice convention, the one exception being the 'i'.
> For me 'm' is better since it is already quite commonly used as
> a member prefix, it connotes "me" or "my", and 'i' (paired with
> 'e') is nice for local iterator pairs. So maybe:
>
>     sFoo   // for static variables
>     mFoo   // for member variables
>     aFoo   // for function arguments
>     foo    // local variables have no prefix
>     iFoo   // iterator to foo range
>     eFoo   // end iterator of foo range
>
> ?
>

I don't like it; your iterator prefixes contradict the other prefixes: 
an iterator variable can be a function parameter, member variable or 
local variable.  Quite often I will simply use standalone "i" or "e" for 
local iterator variables (assuming I have just the one iterator in scope 
of course).

Also I quite like "i" instead of "m" (it is consistent with a large body 
of Symbian code) and "i" is a cool prefix (ask Apple) :).

/Leigh

On Dec 31 2010, 3:30=A0pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 31/12/2010 08:54, James Kanze wrote:
>
>
>
>
>
> > On Dec 31, 6:07 am, Ebenezer<woodbria...@gmail.com> =A0wrote:
> >> On Dec 21, 6:44 am, Leigh Johnston<le...@i42.co.uk> =A0wrote:
>
> >>> On 20/12/2010 18:44, Marco wrote:
>
> >>>> It seems that the most common naming convention for class
> >>>> instance attributes these days (from C++ books) is the
> >>>> trailing underscore. When did this style become the
> >>>> "fashion" leader?
>
> >>>> What member data naming convention are folks using for
> >>>> their C++ production software?
>
> >>> I use the following:
>
> >>> sFoo =A0 =A0// for static variables
> >>> iFoo =A0 =A0// for member variables, "i" stands for "instance"
>
> >> Taligent used fMemberName -- I think the f was short for field.
>
> >>> aFoo =A0 =A0// for function arguments
> >>> foo =A0 =A0 // local variables have no prefix
>
> >> In another recent thread on this topic someone suggested
> >> not putting "warts" on member names but on local variables
> >> since their scope is more limited.
>
> > This goes against another rule I've heard: the length of
> > a variable name should be inversely proportional to its scope.
> > I regularly use names like i and j for loop indexes (and I'd
> > definitely not want to prefex them), but no where else.
>
> Yet another bullshit rule Mr Kanze. =A0

who rattled your cage?

> Just because "i" is acceptable as a
> local variable name (for loop index) does not suddenly make the
> generalization that "variable name should be inversely proportional to
> its scope" valid.
>
> struct point
> {
> =A0 =A0 =A0 =A0 int x;
> =A0 =A0 =A0 =A0 int y;
>
> };

yes but the unadorned names aren't available. You have to use
thePoint.x or thePointP->x. And then we're back to discussing the
scope of thePoint rather than the scope of point.

On Dec 31 2010, 4:35=A0pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 31/12/2010 16:24, Ebenezer wrote:
>
>
>
>
>
> > On Dec 31, 2:54 am, James Kanze<james.ka...@gmail.com> =A0wrote:
> >> On Dec 31, 6:07 am, Ebenezer<woodbria...@gmail.com> =A0wrote:
>
> >>> On Dec 21, 6:44 am, Leigh Johnston<le...@i42.co.uk> =A0wrote:
> >>>> On 20/12/2010 18:44, Marco wrote:
> >>>>> It seems that the most common naming convention for class
> >>>>> instance attributes these days (from C++ books) is the
> >>>>> trailing underscore. When did this style become the
> >>>>> "fashion" leader?
> >>>>> What member data naming convention are folks using for
> >>>>> their C++ production software?
> >>>> I use the following:
> >>>> sFoo =A0 =A0// for static variables
> >>>> iFoo =A0 =A0// for member variables, "i" stands for "instance"
> >>> Taligent used fMemberName -- I think the f was short for field.
> >>>> aFoo =A0 =A0// for function arguments
> >>>> foo =A0 =A0 // local variables have no prefix
> >>> In another recent thread on this topic someone suggested
> >>> not putting "warts" on member names but on local variables
> >>> since their scope is more limited.
>
> >> This goes against another rule I've heard: the length of
> >> a variable name should be inversely proportional to its scope.
> >> I regularly use names like i and j for loop indexes (and I'd
> >> definitely not want to prefex them), but no where else.
>
> > Jeff Schwab and others have suggested using ii and jj rather
> > than just i and j. =A0I think that's partly to make variables
> > easier to pick up. =A0Adding a one character prefix to a one or
> > two character variable gives a length of two or three. =A0I'm
> > just trying it out at this point.
>
> > Do any impose upper limits for variable lengths?
>
> You are trolling.

no he's making a technical point with which you disagree.


>=A0The number of characters in a variable name is an
> irrelevant metric; what is important is to have a meaningful variable
> name which has nothing to do with the number of characters modulo any
> coding standard requirement to have a prefix.

I don't agree. I don't think its a one-to-one mapping but longer names
do get to be a pain and short names invite name space collisions.


> A compiler may impose an upper limit on symbol name length.


I worked with someone who liked long names. He ended up with names
that weren't unique because he's exceeded the compiler limit. 31
characters I think

On Dec 31 2010, 12:58=A0am, =D6=F6 Tiib <oot...@hot.ee> wrote:
> On Dec 30, 11:08=A0pm, Juha Nieminen <nos...@thanks.invalid> wrote:
>
> > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > >> The problem with a trailing underscore is that it makes code visuall=
y
> > >> more confusing (especially when the underscore is followed by other
> > >> symbols such as dots or dashes). Using a letter prefix is less confu=
sing
> > >> (and also gives more possibilities, ie. using different letters for
> > >> different types of variables).
>
> > > guk! And this leads to the hungarian madness!
>
> > =A0 How does using the 'm' prefix (as opposed to the '_' prefix) "lead =
to
> > hungarian madness"?
>
> Opposed to underscore suffix. Nothing leads to madness. Usually the
> discussions of code style conventions ... just turn into such
> emotional "ugly", "confusing", "mad", etc. madness. In practice worst
> is lack of consistency. So when gathering team then it is best to
> argue, vote and write it down as policy. Whatever strange it is ... if
> used consistently the code base feels more uniform.

"using different letters for different types of variables" sounds
excatly like an invitation to hungarian. I've just been introduced to
a large hungarian code base and I'm not enjoying the experience.

On 02/01/2011 13:26, Nick Keighley wrote:
> On Dec 31 2010, 4:35 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 31/12/2010 16:24, Ebenezer wrote:
>>
>>
>>
>>
>>
>>> On Dec 31, 2:54 am, James Kanze<james.ka...@gmail.com>    wrote:
>>>> On Dec 31, 6:07 am, Ebenezer<woodbria...@gmail.com>    wrote:
>>
>>>>> On Dec 21, 6:44 am, Leigh Johnston<le...@i42.co.uk>    wrote:
>>>>>> On 20/12/2010 18:44, Marco wrote:
>>>>>>> It seems that the most common naming convention for class
>>>>>>> instance attributes these days (from C++ books) is the
>>>>>>> trailing underscore. When did this style become the
>>>>>>> "fashion" leader?
>>>>>>> What member data naming convention are folks using for
>>>>>>> their C++ production software?
>>>>>> I use the following:
>>>>>> sFoo    // for static variables
>>>>>> iFoo    // for member variables, "i" stands for "instance"
>>>>> Taligent used fMemberName -- I think the f was short for field.
>>>>>> aFoo    // for function arguments
>>>>>> foo     // local variables have no prefix
>>>>> In another recent thread on this topic someone suggested
>>>>> not putting "warts" on member names but on local variables
>>>>> since their scope is more limited.
>>
>>>> This goes against another rule I've heard: the length of
>>>> a variable name should be inversely proportional to its scope.
>>>> I regularly use names like i and j for loop indexes (and I'd
>>>> definitely not want to prefex them), but no where else.
>>
>>> Jeff Schwab and others have suggested using ii and jj rather
>>> than just i and j.  I think that's partly to make variables
>>> easier to pick up.  Adding a one character prefix to a one or
>>> two character variable gives a length of two or three.  I'm
>>> just trying it out at this point.
>>
>>> Do any impose upper limits for variable lengths?
>>
>> You are trolling.
>
> no he's making a technical point with which you disagree.
>
>
>>   The number of characters in a variable name is an
>> irrelevant metric; what is important is to have a meaningful variable
>> name which has nothing to do with the number of characters modulo any
>> coding standard requirement to have a prefix.
>
> I don't agree. I don't think its a one-to-one mapping but longer names
> do get to be a pain and short names invite name space collisions.

Number of characters in a variable name is an irrelevant metric.  One 
uses named scopes such as classes or namespaces to avoid "name space 
collisions".

>
>
>> A compiler may impose an upper limit on symbol name length.
>
>
> I worked with someone who liked long names. He ended up with names
> that weren't unique because he's exceeded the compiler limit. 31
> characters I think

Sounds like a shit compiler especially if it didn't warn about truncation.

/Leigh

On 02/01/2011 13:22, Nick Keighley wrote:
> On Dec 31 2010, 3:30 pm, Leigh Johnston<le...@i42.co.uk>  wrote:
>> On 31/12/2010 08:54, James Kanze wrote:
>>
>>
>>
>>
>>
>>> On Dec 31, 6:07 am, Ebenezer<woodbria...@gmail.com>    wrote:
>>>> On Dec 21, 6:44 am, Leigh Johnston<le...@i42.co.uk>    wrote:
>>
>>>>> On 20/12/2010 18:44, Marco wrote:
>>
>>>>>> It seems that the most common naming convention for class
>>>>>> instance attributes these days (from C++ books) is the
>>>>>> trailing underscore. When did this style become the
>>>>>> "fashion" leader?
>>
>>>>>> What member data naming convention are folks using for
>>>>>> their C++ production software?
>>
>>>>> I use the following:
>>
>>>>> sFoo    // for static variables
>>>>> iFoo    // for member variables, "i" stands for "instance"
>>
>>>> Taligent used fMemberName -- I think the f was short for field.
>>
>>>>> aFoo    // for function arguments
>>>>> foo     // local variables have no prefix
>>
>>>> In another recent thread on this topic someone suggested
>>>> not putting "warts" on member names but on local variables
>>>> since their scope is more limited.
>>
>>> This goes against another rule I've heard: the length of
>>> a variable name should be inversely proportional to its scope.
>>> I regularly use names like i and j for loop indexes (and I'd
>>> definitely not want to prefex them), but no where else.
>>
>> Yet another bullshit rule Mr Kanze.
>
> who rattled your cage?
>
>> Just because "i" is acceptable as a
>> local variable name (for loop index) does not suddenly make the
>> generalization that "variable name should be inversely proportional to
>> its scope" valid.
>>
>> struct point
>> {
>>          int x;
>>          int y;
>>
>> };
>
> yes but the unadorned names aren't available. You have to use
> thePoint.x or thePointP->x. And then we're back to discussing the
> scope of thePoint rather than the scope of point.
>

You seem to lack an imagination.

Example:

struct point
{
	int x;
	int y;
	void adjust(int xAdjustment, int yAdjustment)
	{
		x += xAdjustment;
		y += yAdjustment;
	}
};

Here the outer class scope has variables names of shorter length than 
the inner function scope.  Mr Kanze's "rule" is not a rule at all but a 
bullshit generalization.

/Leigh

On Jan 2, 2:27=A0pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 02/01/2011 13:26, Nick Keighley wrote
> > On Dec 31 2010, 4:35 pm, Leigh Johnston<le...@i42.co.uk> =A0wrote:
> >> On 31/12/2010 16:24, Ebenezer wrote:
> >>> On Dec 31, 2:54 am, James Kanze<james.ka...@gmail.com> =A0 =A0wrote:
> >>>> On Dec 31, 6:07 am, Ebenezer<woodbria...@gmail.com> =A0 =A0wrote

<snip>

> >>>>> In another recent thread on this topic someone suggested
> >>>>> not putting "warts" on member names but on local variables
> >>>>> since their scope is more limited.
>
> >>>> This goes against another rule I've heard: the length of
> >>>> a variable name should be inversely proportional to its scope.
> >>>> I regularly use names like i and j for loop indexes (and I'd
> >>>> definitely not want to prefex them), but no where else.
>
> >>> Jeff Schwab and others have suggested using ii and jj rather
> >>> than just i and j. =A0I think that's partly to make variables
> >>> easier to pick up. =A0Adding a one character prefix to a one or
> >>> two character variable gives a length of two or three. =A0I'm
> >>> just trying it out at this point.
>
> >>> Do any impose upper limits for variable lengths?
>
> >> You are trolling.
>
> > no he's making a technical point with which you disagree.
>
> >> =A0 The number of characters in a variable name is an
> >> irrelevant metric; what is important is to have a meaningful variable
> >> name which has nothing to do with the number of characters modulo any
> >> coding standard requirement to have a prefix.
>
> > I don't agree. I don't think its a one-to-one mapping but longer names
> > do get to be a pain and short names invite name space collisions.
>
> Number of characters in a variable name is an irrelevant metric.

stalemate by repetition of position

>=A0One
> uses named scopes such as classes or namespaces to avoid "name space
> collisions".
>
> >> A compiler may impose an upper limit on symbol name length.
>
> > I worked with someone who liked long names. He ended up with names
> > that weren't unique because he's exceeded the compiler limit. 31
> > characters I think
>
> Sounds like a shit compiler especially if it didn't warn about truncation=
..

oh it gave an error because the same variable was declared twice, if I
recall correctly. I just find it amazing someone could hit the limit
without really trying. It allowed longer names it just didn't use the
ones past 32 to determine uniqueness

   int z_really_really_long_name_a;
   int z_really_really_long_name_b;

except they were even longer

On Dec 31 2010, 4:24 pm, Ebenezer <woodbria...@gmail.com> wrote:
> On Dec 31, 2:54 am, James Kanze <james.ka...@gmail.com> wrote:

   [...]
> > This goes against another rule I've heard: the length of
> > a variable name should be inversely proportional to its scope.
> > I regularly use names like i and j for loop indexes (and I'd
> > definitely not want to prefex them), but no where else.

> Jeff Schwab and others have suggested using ii and jj rather
> than just i and j.  I think that's partly to make variables
> easier to pick up.  Adding a one character prefix to a one or
> two character variable gives a length of two or three.  I'm
> just trying it out at this point.

I'm not sure I understand the issue.  Any decent editor will
allow searching for a complete word i.

> Do any impose upper limits for variable lengths?

Not formally.  Common sense seems to suffice in this case
(although I once encountered a programmer who regularly used
names over a 100 characters in length).

--
James Kanze

Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> "using different letters for different types of variables" sounds
> excatly like an invitation to hungarian. I've just been introduced to
> a large hungarian code base and I'm not enjoying the experience.

  It's not out of the realm of possibility that you are simply being
prejudiced and not even trying to actually use the naming convention
used in that code to your advantage (ie. to help you read the code
more easily).

Juha Nieminen <nospam@thanks.invalid> writes:
>> "using different letters for different types of variables" sounds
>> excatly like an invitation to hungarian. I've just been introduced to
>> a large hungarian code base and I'm not enjoying the experience.
>
>   It's not out of the realm of possibility that you are simply being
> prejudiced and not even trying to actually use the naming convention
> used in that code to your advantage (ie. to help you read the code
> more easily).

It's also not out of the realm of possibility that a meteoroid will
flatten your house in the next day.  Still, it seems a poor bet.

-Miles

-- 
Bore, n. A person who talks when you wish him to listen.

On Tue, 2010-12-21, Juha Nieminen wrote:
> Drew Lawson <drew@furrfu.invalid> wrote:
>> I originally scoffed at any such notations.  But over time, I've
>> fallen in with the trailing underscore.  When I'm looking at code
>> that isn't fresh, it is helpful to me to see that a symbol is in
>> the instance, so I don't get annoyed at not being able to see the
>> declaration.
>
>   The problem with a trailing underscore is that it makes code visually
> more confusing (especially when the underscore is followed by other
> symbols such as dots or dashes). Using a letter prefix is less confusing
> (and also gives more possibilities, ie. using different letters for
> different types of variables).

It's subjective -- which is why we're having this thread over and over
again!

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .