This C++ teacher instructs his students NOT to do such things. (I
teach Intermediate C++ at the University of Washington and other
places.) Other posters have given the reasons.

Robin

--
---------------------------------------------------------
Robin Rowe    Rowe Techology | Flamers and complainers:
rrowe@halcyon.com            |  If you have nothing to
Northwest C++ Users Group    |   contribute please don't.

Yesterday, while preparing a C++ lesson for my students,
the grace of the COSMIC BIT-TWIDDLER descended upon me
and I felt my consciousness leave my body. Soon my awareness
encompassed the Earth, then solar system, until the Universe
was but a bubble within my omnipresent OneMind.

Suddenly I discerned a subtle vibration filling the void*.
Was it the Cosmic OM? "I" listened closer - Lo! it was

  Use 'p' and 'r' in pointer and reference variable names,
  Use 'p' and 'r' in pointer and reference variable names...

Amazed, "I" experienced waves of ecstasy and bliss. Then the
all pervading FLIP-FLOP spoke:

"I am appointing you the demigod (or was it demagogue?) of
C++ style on Earth. Please spread this wholesome and skillful
message of variable naming. It will save untold hours in
debugging, thus freeing up programmers time to spend in
deep meditation. For example:
   void FooBar(const Person *pPer);
   void FooBar(const Person &rPer);"

I was astounded that the ONE knew about FooBar!
So there you have it. Ignore this advice, and I fear
it will lead to severe retardation of your spiritual
development.

In const,

C++ Demigod of Style (Earth)

[Craig Larman]

|   Suddenly I discerned a subtle vibration filling the void*.
|   Was it the Cosmic OM? "I" listened closer - Lo! it was
|
|     Use 'p' and 'r' in pointer and reference variable names,
|     Use 'p' and 'r' in pointer and reference variable names...
|
|   "I am appointing you the demigod (or was it demagogue?) of
|   C++ style on Earth. Please spread this wholesome and skillful
|   message of variable naming. It will save untold hours in
|   debugging, thus freeing up programmers time to spend in
|   deep meditation. For example:
|      void FooBar(const Person *pPer);
|      void FooBar(const Person &rPer);"

As the * and & become redundant, "const" can be reduced to an initial "c"
in the name, class names can prefix the variable name, and we can do away
with those complex type specifications, altogether.  const Person *per
would become cpPerson_per, and void FooBar (const Person *per) could become
fv_cpPerson_FooBar (per).  This will do away with the need to remember the
type of _any_ object.  Then operators could include the type prefix of
their arguments so debugging would become even easier.  Never mind that
writing code that does not _need_ debugging in the first place will become
next to impossible.

Pointers and references are not trivial for new programmers, but what
better to wish for than that educators instruct so that people can walk
without crutches?  It is disturbing that C++ teachers receive revelations
from the Eternal Bug and are unable to distinguish good from bad.

The suggested scheme is harmful because it instills a false sense of
security in its users, and cripples their ability to read code that does
not use this scheme.  Bugs will be bugs.

As a professional programmer since 1985 and an occasional instructor, I
have found that there is no substitute for reading when one wants to write,
and that exposing students to large amounts of code will more quickly teach
style and consistency than any book of rules and conventions thrown at
them.  Even the American public schools, brain-damaging as they are, do not
suggest that first-graders get a "hands-on experience" with writing before
they have learned the alphabet, and do not prefix words with abbreviations
for parts of speech, not even as a temporary aid before learning to parse.

Best regards,
</Erik>

--
Erik Naggum <erik@naggum.no> <SGML@ifi.uio.no>        Memento, terrigena.
ISO 8879 SGML, ISO 10744 HyTime, ISO 10646 UCS        Memento, vita brevis.

In article <ENAG.94Jan2011707@gyda.ifi.uio.no> enag@gyda.ifi.uio.no (Erik Naggum) writes:
>[Craig Larman]
>
>|   <stuff deleted>
>|     Use 'p' and 'r' in pointer and reference variable names,
>|     Use 'p' and 'r' in pointer and reference variable names...
>|
> <stuff deleted>
>
>Pointers and references are not trivial for new programmers, but what
>better to wish for than that educators instruct so that people can walk
>without crutches?  It is disturbing that C++ teachers receive revelations
>from the Eternal Bug and are unable to distinguish good from bad.
>
>The suggested scheme is harmful because it instills a false sense of
>security in its users, and cripples their ability to read code that does
>not use this scheme.  Bugs will be bugs.
>
> <stuff deleted>
>
>Best regards,
></Erik>
>

It happens that, in my day job, I'm tasked with producing C++
programming standards for a department that is just starting to
use C++. I was taking the p/r proposal seriously. However, a more
important guideline with C++ is to keep methods so short that the
argument declarations are only a few lines away from all code
that uses them. (Names of arguments seem to be more error-provoking
than names of local variables or of member data. Names of arguments
are used only within functions, not in calling them. Unfortunately.)

Chris Perrott

enag@gyda.ifi.uio.no (Erik Naggum) writes:
: [Craig Larman]
:
: |   Suddenly I discerned a subtle vibration filling the void*.
: |   Was it the Cosmic OM? "I" listened closer - Lo! it was
: |
: |     Use 'p' and 'r' in pointer and reference variable names,
: |     Use 'p' and 'r' in pointer and reference variable names...
: |
: |   "I am appointing you the demigod (or was it demagogue?) of
: |   C++ style on Earth. Please spread this wholesome and skillful
: |   message of variable naming. It will save untold hours in
: |   debugging, thus freeing up programmers time to spend in
: |   deep meditation. For example:
: |      void FooBar(const Person *pPer);
: |      void FooBar(const Person &rPer);"
:
: As the * and & become redundant, "const" can be reduced to an initial "c"
: in the name, class names can prefix the variable name, and we can do away
: with those complex type specifications, altogether.  const Person *per
: would become cpPerson_per, and void FooBar (const Person *per) could become
: fv_cpPerson_FooBar (per).  This will do away with the need to remember the
: type of _any_ object.  Then operators could include the type prefix of
: their arguments so debugging would become even easier.  Never mind that
: writing code that does not _need_ debugging in the first place will become
: next to impossible.

Hey! Great! And we can distinguish int variables if we require them to
start with I, J, K, L, M, or N!!!
:-)
--
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work: hendrik@vedge.com,  iros1!vedge!hendrik
at home: uunet!ozrout!topoi!hendrik

Erik Naggum <erik@naggum.no>  says

>As a professional programmer since 1985 and an occasional instructor, I
>have found that there is no substitute for reading when one wants to write,
>and that exposing students to large amounts of code will more quickly teach
>style and consistency than any book of rules and conventions thrown at
>them.  Even the American public schools, brain-damaging as they are, do not
>suggest that first-graders get a "hands-on experience" with writing before
>they have learned the alphabet, and do not prefix words with abbreviations
>for parts of speech, not even as a temporary aid before learning to parse.

Oh I have to agree with Eric, the p and r proposal is useless. However,
THAT doesn't mean that coding standards are not a requirement. Standards
make maintaining someone elses code SO much easier. BUT, hopefully, an
experienced group of developers would throw out this proposal for naming
pointers and references.


BTW: has anyone got an SPP doc for C++ they would be willing to share??


--
------------------------------------------------------------------------------
Andrew Staniszewski
staniszewski@mayo.edu
------------------------------------------------------------------------------