[AccessD] Naming Conventions

And I have no beef with any of that, it is at least a convention.  I or J or
K is not.  Or rather it is a convention, the convention being that in
certain instances we don't use a convention.  Now if we just had a
convention to tell us what instances don't need a convention and what the
implied convention is, well...

Conventions (ANY of them) take time and effort to use.  There is a certain
member who I believe still frequents the list.  One of those top notch minds
who knew what he was doing.  ABSOLUTELY UNREADABLE CODE.  I looked at a lot
of his stuff, hoping against hope to learn something from him.  Nope.

Now I know as well as the next that a For I next I all by itself is not
going to make a piece of code unreadable, but it's the first step to
unreadable code.

John W. Colby
www.ColbyConsulting.com 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Saturday, August 07, 2004 3:56 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Naming Conventions


When I originated this thread, my beef was about Hungarian prefixes. I have
no dispute at all with typing every variable as optimally as possible. My
original contention was the Hungarian prefixes increase noise at the expense
of signal. In my last two projects, I have switched to what I call the
"Object-Action" convention, augmented with Hungarian suffixes rather than
prefixes.

In your example, which refers to no actual objects, my version of your code
might look like this:

<Code>
For WidgetCount_byt = 1 to 250
   'do something
Next WidgetCount_byt
</Code>

When referring to actual (Access) objects, something that I would formerly
have called frmCustomer I now call Customer_frm. The underscore indicates
that what follows is the object/data type. Everything before that follows
standard proper-case notation, with the additional rule that the object of
principal interest (Customer) is followed by the
action(s) taken. In this new naming convention, I would never have a form
called Customer_frm, since it does not specify the actions that can be
taken. Given that four actions can in theory be taken (Select, Insert,
Update, Delete), and that the initial letters of these four actions are
unique, I can then reduce the Action part of the name to a sequence of one
or more letters.

CustomerSIUD_frm -- a form that presents the customer data and allows all
four actions. (Code within the form, testing say user-level, might cause the
Delete action to be unavailable, but that is beside the point,
IMO.)

What has really pleased me about this convention is the sort order in the
database window. I don't have to look four letters in to find the objects
relevant to any given table (i.e. learn to ignore the "frm" prefixes in the
Form window -- no longer necessary -- I can type a "C" and maybe Customers
is not the first table beginning with C but I'm close, right away.

Arthur

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby
Sent: Saturday, August 07, 2004 3:07 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Naming Conventions


It's really quite simple the why.  Because we use a naming convention. We
don't "sometimes, when we feel like it, if it's not raining, if the moon is
out, if I'm not pissed at the boss, its just a loop counter for petes sake"
name things by the convention.  We use a naming convention. Or we don't.  I
is not a naming convention.  intI or lngI or bytI or whatever, yes, that is
a naming convention.  Not a great one.  Variables are supposed to named to
tell us what they represent.

For bytWidgetCnt = 1 to 250
Next bytWidgetCnt

THAT is a naming convention.  I can see by the name what the data type is,
and I can see by the name what it counts.

I realize that quick and dirty programming takes place.  I know that quick
and dirty programs end up transforming into critical applications for
companies.  I discovered a long time ago that every time I failed to use my
convention, it made it that much easier to NOT use the convention the next
time.  I learned a long time ago that every time I USED the convention, it
made it that much easier to USE the convention the next time.

I make no claim to perfection, however I do TRY to use the convention, I TRY
to use it all the time, and I even go back and clean up code where I didn't.
Really!

John W. Colby
www.ColbyConsulting.com 

-- 
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com