Hi imr1984,

imr1984 wrote:
> What do you guys prefix to your private member variables, so that later you can
> create a property to access it later on?

All of my variables are prefixed with the first letters of their type. i.e. a variable of a string is usually cObjectName and a variable of SomeWidget would be called swFunkyBox. I personally don't like underscore prefixes, names like some_name don't bother me as bad but, _imaVariable just seems ugly to me.

-JC

In article <d466g7$1237$1@digitaldaemon.com>, Joshua Cearley says...
>
>Hi imr1984,
>
>imr1984 wrote:
>> What do you guys prefix to your private member variables, so that later you can create a property to access it later on?
>
>All of my variables are prefixed with the first letters of their type. i.e. a variable of a string is usually cObjectName and a variable of SomeWidget would be called swFunkyBox. I personally don't like underscore prefixes, names like some_name don't bother me as bad but, _imaVariable just seems ugly to me.

You're not the only one who feels this way.  Many people find that underscores in identifiers makes for difficult reading.  There is some scientific evidence to back this up.

http://members.aol.com/twoeyedox/vision.htm
(it's not a research paper, but its the best I could do for 1 minute of
googling)

Basically, we (at least in Romantic languages anyway) tend to read by recognizing the tops of letters first.  This is why text THAT IS ALL IN CAPTIAL LETTERS is difficult to read, since the tops of those letters have more in common than lowercase.  As for underscores, one has to scan *downwards* as well as left to right to make sure that isn't a space_or_an_underscore.

Also, its relative positioning to the letters around it are also the only que one has to distinguish it from a hyphen (-).  As an example, Mixing-these_two-can_make-underscores_and-hyphens_hard-to_distingush.

Anyway, using underscores in identifiers, makes things *harder* to read since it requires more effort on our eyes and brains.  Hence the typical reaction: "good bob that's ugly!"

Sticking to a scheme likeInterCaps, works better for most people since you're using the uppercase letters to break the reader's horizontal scanning behavior. It's more effective because uppercase letters stick *up* above the lowercase, instead of below, as with underscores.

IMO, underscores only really add value in languages that are *not* case-sensitive like in SQL.  They help since using intercaps fails to catch erros in such invironments.

- EricAnderton at yahoo

In article <d46849$13cv$1@digitaldaemon.com>, pragma says...
>
>In article <d466g7$1237$1@digitaldaemon.com>, Joshua Cearley says...
>>
>>Hi imr1984,
>>
>>imr1984 wrote:
>>> What do you guys prefix to your private member variables, so that later you can create a property to access it later on?
>>
>>All of my variables are prefixed with the first letters of their type. i.e. a variable of a string is usually cObjectName and a variable of SomeWidget would be called swFunkyBox. I personally don't like underscore prefixes, names like some_name don't bother me as bad but, _imaVariable just seems ugly to me.
>
>You're not the only one who feels this way.  Many people find that underscores in identifiers makes for difficult reading.  There is some scientific evidence to back this up.
>
>http://members.aol.com/twoeyedox/vision.htm
>(it's not a research paper, but its the best I could do for 1 minute of
>googling)
>
>Basically, we (at least in Romantic languages anyway) tend to read by recognizing the tops of letters first.  This is why text THAT IS ALL IN CAPTIAL LETTERS is difficult to read, since the tops of those letters have more in common than lowercase.  As for underscores, one has to scan *downwards* as well as left to right to make sure that isn't a space_or_an_underscore.
>
>Also, its relative positioning to the letters around it are also the only que one has to distinguish it from a hyphen (-).  As an example, Mixing-these_two-can_make-underscores_and-hyphens_hard-to_distingush.
>
>Anyway, using underscores in identifiers, makes things *harder* to read since it requires more effort on our eyes and brains.  Hence the typical reaction: "good bob that's ugly!"
>
>Sticking to a scheme likeInterCaps, works better for most people since you're using the uppercase letters to break the reader's horizontal scanning behavior. It's more effective because uppercase letters stick *up* above the lowercase, instead of below, as with underscores.
>
>IMO, underscores only really add value in languages that are *not* case-sensitive like in SQL.  They help since using intercaps fails to catch erros in such invironments.
>
>- EricAnderton at yahoo


I agree, but in D they are neccessary because you have to differentiate between member variables and properties, so youve got to use either ugly underscores or ugly hungarian notation. I dont like either grrr.

"pragma" <pragma_member@pathlink.com> wrote in message news:d46849$13cv$1@digitaldaemon.com...
> In article <d466g7$1237$1@digitaldaemon.com>, Joshua Cearley says...
> Anyway, using underscores in identifiers, makes things *harder* to read
> since it
> requires more effort on our eyes and brains.  Hence the typical reaction:
> "good
> bob that's ugly!"
> Sticking to a scheme likeInterCaps, works better for most people since
> you're
> using the uppercase letters to break the reader's horizontal scanning
> behavior.
> It's more effective because uppercase letters stick *up* above the
> lowercase,
> instead of below, as with underscores.

I agree, which is why I only use them for _memberVariables, as I hate hungarian notation (is it just me or is MS-developed code some of the most confusing stuff you can find simply because of the variable names?!).  I suppse simply prefixing member variables with an 'm' would be a viable alternative, i.e. mPosition, mText etc.

Jarrett Billingsley wrote:
> "pragma" <pragma_member@pathlink.com> wrote in message news:d46849$13cv$1@digitaldaemon.com...
> 
>>In article <d466g7$1237$1@digitaldaemon.com>, Joshua Cearley says...
>>Anyway, using underscores in identifiers, makes things *harder* to read since it
>>requires more effort on our eyes and brains.  Hence the typical reaction: "good
>>bob that's ugly!"
>>Sticking to a scheme likeInterCaps, works better for most people since you're
>>using the uppercase letters to break the reader's horizontal scanning behavior.
>>It's more effective because uppercase letters stick *up* above the lowercase,
>>instead of below, as with underscores.
> 
> 
> I agree, which is why I only use them for _memberVariables, as I hate hungarian notation (is it just me or is MS-developed code some of the most confusing stuff you can find simply because of the variable names?!).  I suppse simply prefixing member variables with an 'm' would be a viable alternative, i.e. mPosition, mText etc. 

That might be a good choice.

On Wed, 20 Apr 2005 19:05:51 +0000 (UTC), imr1984 wrote:

> In article <d46849$13cv$1@digitaldaemon.com>, pragma says...
>>
>>In article <d466g7$1237$1@digitaldaemon.com>, Joshua Cearley says...
>>>
>>>Hi imr1984,
>>>
>>>imr1984 wrote:
>>>> What do you guys prefix to your private member variables, so that later you can create a property to access it later on?
>>>
>>>All of my variables are prefixed with the first letters of their type. i.e. a variable of a string is usually cObjectName and a variable of SomeWidget would be called swFunkyBox. I personally don't like underscore prefixes, names like some_name don't bother me as bad but, _imaVariable just seems ugly to me.
>>
>>You're not the only one who feels this way.  Many people find that underscores in identifiers makes for difficult reading.  There is some scientific evidence to back this up.
>>
>>http://members.aol.com/twoeyedox/vision.htm
>>(it's not a research paper, but its the best I could do for 1 minute of
>>googling)
>>
>>Basically, we (at least in Romantic languages anyway) tend to read by recognizing the tops of letters first.  This is why text THAT IS ALL IN CAPTIAL LETTERS is difficult to read, since the tops of those letters have more in common than lowercase.  As for underscores, one has to scan *downwards* as well as left to right to make sure that isn't a space_or_an_underscore.
>>
>>Also, its relative positioning to the letters around it are also the only que one has to distinguish it from a hyphen (-).  As an example, Mixing-these_two-can_make-underscores_and-hyphens_hard-to_distingush.
>>
>>Anyway, using underscores in identifiers, makes things *harder* to read since it requires more effort on our eyes and brains.  Hence the typical reaction: "good bob that's ugly!"
>>
>>Sticking to a scheme likeInterCaps, works better for most people since you're using the uppercase letters to break the reader's horizontal scanning behavior. It's more effective because uppercase letters stick *up* above the lowercase, instead of below, as with underscores.
>>
>>IMO, underscores only really add value in languages that are *not* case-sensitive like in SQL.  They help since using intercaps fails to catch erros in such invironments.
>>
>>- EricAnderton at yahoo
> 
> I agree, but in D they are neccessary because you have to differentiate between member variables and properties, so youve got to use either ugly underscores or ugly hungarian notation. I dont like either grrr.

I've held back on this topic because of the 'war' factor. But here we go anyways ... ;-)

My tendency is to prefix identifiers to indicate where they have been defined, and thus to a large degree, their scope. I use a single lowercase character thusly ...

 'm'  A (private) member of a class/struct/enum
 'l'  a local variable. Declared inside a block (mostly function blocks)
 'v'  a (private) variable declared at the module level.
 'g'  a public variable.
 'p'  a parameter to a function. For languages that allow pass-by-reference
I supplement this by 'pi' - input param, 'po' output param, 'pu' an in-out
param.

  And if I remember to, I like to place a 'k' after the 'v'/'g' prefixes
for constant literals.

For example:

import std.stdio;
  class Foo
  {
      private int mSomeValue;
      int SomeValue() { return mSomeValue; }
      void SomeValue(int x) { mSomeValue = x * 2; }
  }
  private Foo vModCopy;
  static this()
  {
      vModCopy = new Foo;
  }

  int gBadInt;
  const int gkError = -99;

  int funcA(in int piOne, out int poSet, inout int puWhat)
  {
      static int lCounter;
      poSet = lCounter;
      lCounter += piOne;

      if (piOne > 1)
          puWhat++;
      return lCounter;
   }

   int main()
   {
      int lPrev;
      int lCheck;

      vModCopy.SomeValue(7);
      writefln("%d %d %d", funcA( vModCopy.SomeValue, lPrev, lCheck),
		 lPrev, lCheck);
      writefln("%d %d %d", funcA( vModCopy.SomeValue, lPrev, lCheck),
		 lPrev, lCheck);
      writefln("%d %d %d", funcA( vModCopy.SomeValue, lPrev, lCheck),
		 lPrev, lCheck);
      writefln("%d %d %d", funcA( vModCopy.SomeValue, lPrev, lCheck),
		lPrev, lCheck);
      return 0;
   }


People who have used this, tend to say that they like the fact that they don't have to search through code to locate where variables where declared and it alerts them to possible misuse. It also help to avoid clashes with language keywords.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build/ v2.03 released 20/Apr/2005
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
21/04/2005 10:24:43 AM

Derek Parnell wrote:
> My tendency is to prefix identifiers to indicate where they
> have been defined, and thus to a large degree, their scope.
> I use a single lowercase character thusly ...
> 
>  'm'  A (private) member of a class/struct/enum
>  'l'  a local variable. Declared inside a block (mostly
>       function blocks)
>  'v'  a (private) variable declared at the module level.
>  'g'  a public variable.
>  'p'  a parameter to a function. For languages that allow
>       pass-by-reference
>
> I supplement this by 'pi' - input param, 'po' output param,
> 'pu' an in-out param.
> 
> And if I remember to, I like to place a 'k' after the
> 'v'/'g' prefixes for constant literals.
> 
> People who have used this, tend to say that they like the
> fact that they don't have to search through code to locate
> where variables where declared and it alerts them to possible
> misuse. It also help to avoid clashes with language keywords.

This is a good one. And, as you said, the war factor almost
prohibits even discussing these things. It's like which editor
one should use.

It's all a matter of personal preferences. Some people have
a hard time remembering the type of a variable, so they
prefix variables with that. Others again have other things
they "need" the prefixes for.

And, of course, there's the religion against prefixes at all.

Personally, I find your style quite informative and I feel
it really helps, and makes the code clearer even for the
casual reader. It may also save time, even more when one
becomes intuitively accustomed to these prefixes -- less
searching around the code for definitions.

You see this is my dilemma: I want to organise my programs in an OO fashion, and I see the value of protecting data in large programs. But to do this I have to either make my properties have mangled names, or my member variables have mangled names; and I think both these methods look really bad. Its such a shame that you cant both named with the standard D convention eg int myVar;