NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/pascal/8616

Text File | 1993-01-28 | 7.5 KB | 183 lines

Newsgroups: comp.lang.pascal
Path: sparky!uunet!news.univie.ac.at!scsing.switch.ch!univ-lyon1.fr!ghost.dsi.unimi.it!rpi!utcsri!newsflash.concordia.ca!sifon!thunder.mcrcim.mcgill.edu!poly-vlsi!music.mus.polymtl.ca
From: Steph <[e-mail]>
Subject: Naming conventions
Message-ID: <[e-mail]>
Lines: 172
Sender: [e-mail]
Organization: Ecole Polytechnique de Montreal
Date: Tue, 26 Jan 1993 14:54:24 GMT

My server, and account, were down for the past 3 days so I wasn't
able to reply to any messages.  I think my reply about one other
message didn't get through.  Doesn't matter, it was sort of
flamish.  Anyhow, here's another one I did:

In article <[e-mail]> [e-mail] (S. A. Modena) writes:
>In article <[e-mail]> [e-mail] (Paul Furbacher) writes:
>>In article <[e-mail]>,
>>[e-mail] (Steph) wrote:

[ my stuff deleted ]
>>>
>>> Okay, let's assume I have an object definition that _looks_ like
>>> this:
>>>
>>> PObjectType         = ObjectType;
>>> ObjectType          = OBJECT
>>>   Stuff             : StaticRecord;
>>>   Stuff2            : PtrRecord;
>>> ............
>>
>>> Stuff2 = RECORD x,y,z : WORD; Buf : POINTER; END;

Okay, if you guys want to nitpick ...

  1) PObjectType should read ...

     PObjectType        = ^ObjectType;

     I'm amazed no one has screamed murder on that one yet.

  2) It's not Stuff2 that should be defined as a RECORD .. END, but PtrRecord,
     like so:

     PtrRecord = ^RECORD .. END;

     Again, no one complained.  Strange world.

[ more of my stuff deleted, as was as Paul Furbacher's ]

>
>To carry Paul's critique of Steph's code just a bit farther to make
>a general point.
>

Ooooh boy, this should be educational, and oh-so entertaining.

>Steph does this:
> Stuff: StaticRecord;
> Stuff2: PtrRecord;
>
>Let's consider what this communicates to a stranger (which is the code
>writer himself one month later).
>
>Try these alternative declarations:
           ^^^^^^^^^^^
You said it yourself, Steve.

>
>TYPE TStaticRecord = RECORD....
>TYPE PStaticRecord = ^TStaticRecord;
>
> StaticRecord: TStaticRecord;
> StaticRecordP: PStaticRecord;
>
>Notice that my naming convention is quite suggestive of what the hell I
             ^^
>am dealing with when I use those identifiers farther down in the code.  :^)
>
>Of course, I've be told that "all that typing" is so *tedious,* but it gives
>so much *help* when I'm debugging my own code.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^
Matter of opinion, I guess.  If I were to debug code that used StaticRecord
and StaticRecordP, I'd be wary the programmer confused the two.  I would, in
my own code, use something like StaticRecordPtr to define the pointer record,
but that is only _me_.  And, to skin it to death, a PointerToAStaticRecord
could be misleading to some other programmers.  It would be a
PointerToADynamicRecord, no?  ;)

>
> "Stuff" tells me absolutely nothing about itself, so I am
>free to absent-mindedly do any old nonsense that pops into my head.

*BINGO*.  You got that one right, at least.  That's exactly the point of
putting a variable name as Stuff in an EXAMPLE.  It succeeded it telling
you this much : the content could be _anything_ and is _not_ relevant to
the example.  Pretty good, *clap* *clap*.

>
> "Stuff2" real, truely tells me even *less*.......not even the
> same *storage* type........and the

Ooops, I take it back -- you didn't get the real point of the Stuff
variables.  Of course Stuff2 can't tell you more, it's nothing important
again.  And since it's not the same storage space, and not the same name,
what does this tell us?  Different _stuff_, that's all.

>        "PtrRecord" is disasterously misleading.
>

Is it?  In an example, all it does is inform me that we are dealing with a
pointer pointing to a dynamic variable that is, in fact, a data structure.
PtrRecord, Pointer-to-a-Record.  In a program, maybe it would be misleading,
maybe_.  If someone uses it all the time and defines their dynamic records
types as Ptr<RecordName> or <RecordName>Ptr, as long as they are consistant,
it makes sense to me.

>An friend who is an electronics manufacturing engineer assures me that
>"they" are always in such a hurry to get the "job" done, that following
>simple, standard set up and quality procedures is "such a waste of time",
>that invariably the "job" has to be redone, and redone and redone until
>they finally get it right.
>
>So how is Pascal coding different?  No, coding conventions do not prevent
>the occurance of bugs, but they do *significantly* reduce the number of
>"silly" bugs (aren't most of them silly?) and significantly reduce the amount
>of time needed to debug....and, believe it or not, sometimes promotes
>clear thinking to the point of coding it right-the-first-time, more often.
>
>Look back above at Steph's naming convention (pretty much like yours,
                    ^^^^^^^^^^^^^^^^^^^^^^^^^
>right?) and pay attention to how it helped him dig himself in royally!
>I can easily see *why* the FillChar() bug flowed from his type declarations
>and naming non-conventions.
            ^^^^^^^^^^^^^^^^

*OUCH*  If you can, from a 5-line declaration header _example_, deduce my
naming convention then either you are a psychic, or full of yourself.

"Your" naming convention is not new to me; I use it when I write Turbo Vision
programs, because that is the way Borland wants us to go.  It would be foolish
to use something else in a Turbo Vision program, because the code simply
wouldn't flow when merged when Turbo Vision's numerous objects.

Now, it would also be really foolish of me to throw away my naming convention
I have been using since Turbo Pascal 3.0, before Turbo Vision came to be.  I
stick to it because it passed the test of time, it still works for me, and I
can go back and write old code I wrote years ago and still understand it.
More so, people that read my code usually can follow my style pretty easily.
Isn't that what's important with a naming convention?

Objects don't equate to Turbo Vision; my example uses objects, but it's far
from being a Turbo Vision package, so I didn't see the need to use TV naming
convention.

>And he was *positive* it was a spurious bug in the compiler--definitely, this
>time, for sure.  :^)  Well, we all do it.  It's just a question time until
>we get smart and quite doing it...or move on to some other way to earn a living.

Again, the old foot-in-the-mouth.  Don't assume I "didn't get smart" yet
because I don't use _your_ (or Turbo Vision's) naming convention.  I penalized
enough students because they don't use significant variable names to know what
I am talking about.  And they is always the ones that think that overdoing it
means better programming.  Not true.

>
>Steve
>---
>+------------------------------------------------------------------+
>|     In person:  Steve Modena     AB4EL                           |
>|     On phone:   [phone]                                   |
>|     At e-mail:  [e-mail]                           |
>|                 [e-mail]                |
>|                 [ either email address is read each day ]        |
>|     By snail:   Crop Sci Dept, Box 7620, NCSU, Raleigh, NC 27695 |
>+------------------------------------------------------------------+
>         Lighten UP!  It's just a computer doing that to you.    (c)
>OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

Steph.
Hey, I can make mistakes too.