🚀 go-pugleaf

In article <4hstf8$jf3@cybernews.cyberus.ca> robert_mohid@cyberus.ca (Robert Mohid) writes:
>I've been recently told that the practice of prefixing functions to
>indicate return type (ie: int iGetInt(void)   ) is "part of a new
>approach in progrmming". Can anyone confirm/deny this? I am extremely
>skeptical about that last statement, and to any who would reply
>*please* include some references as to make your claims as irrefutable
>as possible.	Thanks in advance.

Well, it's a slightly newish thing.  Microsoft decided to use it(*) in
their Windows code.  Many (many many!) people think it makes the names
much harder to read -- if I wanted to look at names with lots of type
information in them, I'd look at the output of a C++ translator.

Allen Holub has a wonderful bit on Hungarian notation in his book "Enough
Rope to Shoot Yourself in the Foot" (ISBN 0-07-029689-8), rule number 44.1.
The basic part of the rule is "Do not clutter names with gibberish."  The
details of the rule expand the definition of gibberish to include leading
weird type stuff, as well as starting pointer names with p.

(*)it == Hungarian Notation, after the native country of Microsoft's
head of programming, Charles Simonyi, who invented it.  Holub also
explains why it is useful in one particular (assembly language) context.
-- 
Steve Watt KD6GGD  PP-ASEL              Packet: KD6GGD @ N0ARY.#NOCAL.CA.USA.NA
ICBM: 121W 56' 53.1" / 37N 20' 16.7"      Internet: Home: {root,steve}@Watt.COM
"I am always ready to learn, although I don't always like being taught."
                                                         -- Winston Churchill

[ posted for aps@symbionics.com by steve@Watt.COM ]

To: Steve Watt -- KD6GGD <steve@Watt.COM>
From: Adrian P Stephens <aps@symbionics.co.uk>
Date: Mon, 18 Mar 1996 12:41:43 +0000

(Steve,  please could you post this to comp.std.c for me,  my news out
 feed is broken.  Thankx.)


Steve Watt -- KD6GGD wrote:
> 
> In article <4hstf8$jf3@cybernews.cyberus.ca> robert_mohid@cyberus.ca (Robert Mohid) writes:
> >I've been recently told that the practice of prefixing functions to
> >indicate return type (ie: int iGetInt(void)   ) is "part of a new
> >approach in progrmming". Can anyone confirm/deny this? I am extremely   <<++>>
> >skeptical about that last statement, and to any who would reply
> >*please* include some references as to make your claims as irrefutable
> >as possible.   Thanks in advance.
> 
> Well, it's a slightly newish thing.  Microsoft decided to use it(*) in
> their Windows code.  Many (many many!) people think it makes the names
> much harder to read -- if I wanted to look at names with lots of type
> information in them, I'd look at the output of a C++ translator.

Love them or loath them,  standards are important to any company.  Ours
has "C" coding standards which require this kind of thing.   Initially
I was against it,  because it makes things cluttered,   lengthens lines
of code and makes for more typing.

Our standards also require explicit
identification of the size returned if it is an integer.   This is of 
benefit if you are doing emulation/debugging without a symbolic emulator/
debugger (and how many do that??),   but otherwise doesn't allow you to
pretend you've got "opaque types" in "C".   Also,  for some things where
the type is not selected until compile time (e.g. integer sizes and 
size_t particularly) you cannot select a name which is legal in the
sense of these standards.

Here's an example from a bit of code I'm working on now:

extern TX_MANAGEMENT_PKT * psTxManagementPktTXP_NewTxBeaconPkt(void);

Elements required in our standard:

   TX_MANAGEMENT_PKT  - all upper case because it's a typedef/struct
   p                  - pointer to ...
   sTxManagementPkt   - a structure of this type (but case converted)
   TXP                - name of module containing global export
   "NewTxBeaconPkt"   - What I orginally called the routine before
                      - I read our coding standards.


Oh,  and finally another example from real code:

/*--------------------------------------------------------------------------
 * Routine:     u32GetU32
 *
 * Parameters: Name         r/w     Usage
 *              char **     *w      ppcParams
 *                                  
 * Returns:    u32 value
 *
 * Description:
 *      Read and return a u32 value from the command-line,  reading decimal
 *      numbers by default,  or hex if preceded by "0x".
 *--------------------------------------------------------------------------*/
extern u32 u32GetU32(char ** ppcParams);

Which,  I guess,  answers "<<++>>" above.


> [snip] 

Adrian P Stephens

aps@symbionics.co.uk            Symbionics  Ltd
Tel: +44 1223 421025 (work)     St John's Innovation Park
                                Cowley Road
                                Cambridge CB4 4WS,    UK
---------------------------------------------------------

In article <1996Mar18.201616.6958@Watt.COM>,
Adrian P Stephens  <aps@symbionics.co.uk> wrote:
:[ posted for aps@symbionics.com by steve@Watt.COM ]

[hope I got the attributions right]

:Love them or loath them,  standards are important to any company.  Ours

Agreed, but they need to be sensibly chosen.

:has "C" coding standards which require this kind of thing.   Initially
:I was against it,  because it makes things cluttered,   lengthens lines
:of code and makes for more typing.
:
:Our standards also require explicit
:identification of the size returned if it is an integer.   This is of 
:benefit if you are doing emulation/debugging without a symbolic emulator/
:debugger (and how many do that??),   but otherwise doesn't allow you to

I believe there are tools that can produce the type information you
need separately.  Furthermore, if there are large numbers of names
in scope at most points, a design problem probably exists.

Also, it's a distinct anti-benefit if you need to type a debugger
command such as:
	break at psTxManagementPktTXP_NewTxBeaconPkt
to set a breakpoint, for example.

:pretend you've got "opaque types" in "C".   Also,  for some things where
:the type is not selected until compile time (e.g. integer sizes and 
:size_t particularly) you cannot select a name which is legal in the
:sense of these standards.

[snip]

:Here's an example from a bit of code I'm working on now:
:
:extern TX_MANAGEMENT_PKT * psTxManagementPktTXP_NewTxBeaconPkt(void);
:
:Elements required in our standard:
:
:   TX_MANAGEMENT_PKT  - all upper case because it's a typedef/struct
:   p                  - pointer to ...
:   sTxManagementPkt   - a structure of this type (but case converted)
:   TXP                - name of module containing global export
:   "NewTxBeaconPkt"   - What I orginally called the routine before
:                      - I read our coding standards.

Standards like these sacrifice portabiliy, with what seems like
no benefit.  (External identifiers, to be portable, must be unique in
the first six characters, independent of case.)  It would seem to
me that if such names *must* be mandated (which I'm against), the
type information should be on the end, such as
	NewTxBeaconPkt_psTxManagementPktTXP
(also probably more readable).

Also, do you need to rename everything if you change some typedef
from int to long?  (or do the company standards forbid typedefs?)

Cheers,
Stan.
--
Stan Ryckman  (stanr@tiac.net)
  (Apologies for non-responses or late responses to some posts;
  .newsrc was trashed and I'm trying to get it back to where it was.)

In article <1996Mar18.201616.6958@watt.com>,
Adrian P Stephens  <aps@symbionics.co.uk> wrote:
[snip]
>Our standards also require explicit
>identification of the size returned if it is an integer.   This is of 
>benefit if you are doing emulation/debugging without a symbolic emulator/
>debugger (and how many do that??),   but otherwise doesn't allow you to
>pretend you've got "opaque types" in "C".   Also,  for some things where
>the type is not selected until compile time (e.g. integer sizes and 
>size_t particularly) you cannot select a name which is legal in the
>sense of these standards.
>
>Here's an example from a bit of code I'm working on now:
>
>extern TX_MANAGEMENT_PKT * psTxManagementPktTXP_NewTxBeaconPkt(void);

Aaaargh!  All those wishing to avoid working for this company,
please form an orderly queue.  Don't push.

>
>Elements required in our standard:
>
>   TX_MANAGEMENT_PKT  - all upper case because it's a typedef/struct
>   p                  - pointer to ...
>   sTxManagementPkt   - a structure of this type (but case converted)
>   TXP                - name of module containing global export
>   "NewTxBeaconPkt"   - What I orginally called the routine before
>                      - I read our coding standards.
>
>
>Oh,  and finally another example from real code:
>
>/*--------------------------------------------------------------------------
> * Routine:     u32GetU32
> *
> * Parameters: Name         r/w     Usage
> *              char **     *w      ppcParams
> *                                  
> * Returns:    u32 value
> *
> * Description:
> *      Read and return a u32 value from the command-line,  reading decimal
> *      numbers by default,  or hex if preceded by "0x".
> *--------------------------------------------------------------------------*/
>extern u32 u32GetU32(char ** ppcParams);
>
>Which,  I guess,  answers "<<++>>" above.

Which I guess is as damning a condemnation of Hungarian notation as
you're going to get.

John

-- 
John Winters.  Wallingford, Oxon, England.

On Mon, 18 Mar 96 20:16:16 GMT, Adrian P Stephens <aps@symbionics.co.uk> >Ours
>has "C" coding standards which require this kind of thing.   Initially
>I was against it,  because it makes things cluttered,   lengthens lines
>of code and makes for more typing.

It does more than that: it makes the code less supportable.  When the type of
a variable has to change, every occurence of it has to be changed in the text.
It also goes against the philosophical ideal of information hiding, and lulls
the user into not having the compiler/lint perform strict type-checking (since
'it's obvious' what the type is).

I think it's better to give a variable a human-meaningful name that describes
its function, and use the compiler to enforce and report typing problems.

-- 
#include <standard_disclaimer.h>                 http://emoryi.jpl.nasa.gov/
 _
Kevin D Quitt  USA 91351-4454           96.37% of all statistics are made up