[AccessD] Naming Conventions

Charlotte Foust cfoust at infostatsystems.com
Fri Aug 13 12:50:59 CDT 2004


Drew,

Have you *ever* been through a code review?  It doesn't sound like it
because if you had, you would understand why it matters if you can tell
by looking at it.  We don't just rely on running the code to test it, we
spot the obvious errors by looking at it in company.  When someone else
is looking at your code and pointing out egregious errors, you quickly
learn to read it yourself because you're going to have to explain WHY
you did that ... Assuming you can.  

Do you really write code and run it, fix an error, run it, fix an error,
run it, ad nauseum, until you have found all the obvious errors?  If I
find one error, I assume there may be others and read through the code
looking at them.  I'm not saying you can't do it the other way, but I'd
rather have it run without the error messages to tell me I screwed up.
And I *surely* don't want someone else to point out my mistakes to me
when I can spot them for myself if I just look.

Charlotte Foust


-----Original Message-----
From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] 
Sent: Friday, August 13, 2004 9:40 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Naming Conventions


Who cares if you can tell by looking at it.  If you wrote code like
this:

Dim cmb As ComboBox
cmb=Me.cmbSomeCombo

when you tried to run it, it is going to error.  You can't say that
Hungarian prevents you from having brain farts!  No naming convention
will do that.  On top of that, no matter what convention you use, if you
goof, more then likely you won't catch it just by looking at your code
anyways. Ever proof read you're own work?  You're mind has a nifty way
of seeing what it thought it told you to write.....<grin>

The argument that maintenance developers need to 'read' your code
implies that your code is working in the first place.  To successfully
make a change in someones working code, you should understand the ENTIRE
process before changing anything.  Therefore, it shouldn't matter if you
need to read the whole procedure before making a change, because you
should be doing that just to insure that you aren't stepping on the
code's toes.

Still no comment on the With statement.  It seems that so much of this
'Hungarian way or the Highway' is based upon having everything
explicitly laid out in each line.  Wouldn't that same principle mean
that using a With statement is bad practice also, since it is
referencing an object that could be several lines above the line you are
looking at?  If find it odd that I brought it up twice, and had no
'Hungarianonian' chime in about it.  Maybe because if they applied their
principles to the With statement, they wouldn't be able to use it
anymore (and we all know how convenient the With statement can
be.......uh oh....it's convenient....better not use it....LOL)

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Charlotte
Foust
Sent: Friday, August 13, 2004 11:13 AM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Naming Conventions


That's exactly the point, Drew.  If FirstName is a class, then that
statement is invalid.  But you can't tell by looking at it, now can you?
Are you suggesting that you look at the way something is used in code to
determine what kind of thing it is?  You DO turn on Option Explicit
don't you??  Have you have *NEVER* typed something like 

Set Whatever = 5 

or 

Frm = Forms!MyForm  

Charlotte Foust


-----Original Message-----
From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] 
Sent: Thursday, August 12, 2004 6:10 AM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Naming Conventions


Ah, well, now you have a different argument to defend.

How could FirstName be a class, if you have this:

FirstName="Hello"

????

The way a variable is used, will determine what kind of variable you are
dealing with.

If you see:

Set FirstName= .....

It's not a string variable, is it?

On top of that, if it's a property, which could act like a string, then
you would see the Object.Property...unless of course you use a With
statement somewhere.

Does that mean that using a With Statement is bad practice?  Because how
is a maintenance coder supposed to know what object is being used as a
parent, without having to go all the way up to the top to find the With
statement?

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Charlotte
Foust
Sent: Wednesday, August 11, 2004 5:05 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] Naming Conventions


>> Isn't FirstName going to be a string.

No, it could be a class, a property, or something else entirely, Drew.
That's the point, and it's the problem I have with the "recommended"
naming for .Net, where the assumption seems to be that everything is
itself so it doesn't need any additional labelling.

Charlotte Foust


-----Original Message-----
From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] 
Sent: Wednesday, August 11, 2004 1:14 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Naming Conventions


<JC QUOTE>I know that when I'm dealing with money it's gonna be
currency, when I'm dealing with a text well... Uhh... It's gonna be a
string.</JC QUOTE>


So why in the world, would you need strFirstName?  Isn't FirstName going
to be a string.  Except of course, with your new naming convention, we
would all be binary representations.  Surrogate keys for our natural DNA
keys. LOL!

By this same logic, if you see For i=1 to 1000, can't you listen to what
you just said, and realize it's a NUMBER, and even perhaps guess that
it's an integer....more then likely a long integer?

What kills me on this whole thread, is that if you saw these two peices
of
code:

Dim i As Long
For i=1 to 100
	Debug.Print i
Next i


-- AND --

Dim strLetsCountToOneHundred As String
Do Until strLetsCountToOneHundred="100"
	strLetsCountToOneHundred="" & Val(strLetsCountToOneHundred)
	Debug.Print strLetsCountToOneHundred
Loop

You would approve of the second one, because it stuck to your naming
convention, regardless of the fact that it is totally moronic to perform
the task  that way.  You would disregard the first one, because even
though it does exactly what it needs to, is understandable to more then
half of the coders in the world, took a tenth of the time to type
out........it doesn't use Hungarian convention...so it is bad in your
book.  Phooey, go with the inefficient garbage....at least it uses
Hungarian

By the way, good luck with your book.  No, I'm not going to buy a
copy....don't buy any books on programming.....

Drew

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


>My point is that you seem to recommend everyone using the same standard

>and
quotes MS as someone to take lead from when it comes to coding.  They've
*changed* their standard which pretty stuffs up your argument. 

Nope, I said if you went to a large company espousing using I or II as
variable names you would generally be shown the door.

>And strongly typing IS a primary issue in naming conventions.

Precisely right, one very good reason for using a convention such as the
Hungarian is that it tells you the data type of the variable.  It
certainly is NOT a reason for abandoning such a convention.

>Here's 4 valid points of which intellisense is only one.
http://www.fmsinc.com/dotnet/analyzer/Rules/Hungarian.htm

Let's look at them:

>- .NET code is strongly typed, removing the need to identify variable 
>type
by its name.

Excuse me?  What does strongly typed (must be identified as a specific
data type at dim time and can only be assigned that type) have to do
with readability?  Readability is what naming conventions are about.
When I am down buried in code and I come on i, I need to know that I
cannot assign a string to it because it is a currency variable.  The
fact that it is strongly typed is exactly an argument for telling me
what the variable is (naming convention?)!!!

>- .NET has a rich new type system. Coming up with prefixes for all of
>the
new types would tedious and hard to keep track of.

That is undeniable.  Just LEARNING all the types is tedious and hard to
keep track of!  With 2500 (or is it 3500) classes, you certainly can't
come up with a prefix for each.  However, a string is still a string and
an integer is an integer.  It would still be useful to know that when I
try to assign something to that integer I want to make sure that it is
an integer.  

>- In Visual Studio .NET, you simply have to hover over a variable to 
>get
its type. This removes the need to identify a variable's type by its
name.

Bull!  I read code by the acre every day.  To have to move my mouse over
everything in sight is simply ludicrous.

>- Eliminating Hungarian Notation makes code easier to manage, 
>especially
when you decide that you need to change a variable's type (for example,
if you decide to use a double instead of a long).

Bull!  Or I guess what I really mean is "of course it does".  On the
other hand just using i for every variable also makes things easier.
You'd never need to rename anything because everything would already be
named i.  Or II if you were Drew ;-)  

I have used a Hungarian convention for a long time (not that it is the
end all and be all of conventions but at least it qualifies as one!) and
a simple find and replace works wonders for such renaming tasks.
Furthermore I end up changing the data type of variables oh... Hm...
Once in a blue moon.  I know that when I'm dealing with money it's gonna
be currency, when I'm dealing with a text well... Uhh... It's gonna be a
string.  Once in a blue moon I misjudge on the byte/integer/long stuff.
Once in a great while I change a text box to a combo or vv.  Yep, I have
to find and replace.

That is just a silly argument.



So what we come up with is a SINGLE somewhat maybe kinda sorta valid
reason (for .NET specifically).

However I'm on a roll here.  The COLBY convention, everything is named
i. Simple, easy to remember the convention, saves bajillions of
keystrokes, easy to document your convention, never have to strain your
brain to think up new names for things... Yea, that's the ticket.
Hmm... 

Wait.  Let's really develop this.  All variables are named beginning
with a, the next one b and so forth.  Very rare to use more than 26
variables in one place, but if your do... Uh... Ok... Let me think...
This is a tough one... Yea!!!  Let's just go with aa, ab, ac...  COOL!!!
I mean think about it, we could have 26*26 variables before we even had
to go to three characters.  

Perhaps I could write a book on it.  One page, in fact, one paragraph,
explaining the convention.  $69.99 / copy.  No printing costs.  Yea...
Brilliant!

You did say as long as *A* standard is used and it is documented...

Drew, ya want to buy a copy?  And don't EVEN tell me that its YOUR
convention, cause I'm betting you didn't think of the ab thing!

<Huge grin>  OMG I'm gonna be a millionaire.

OMG2.  I just realized I could write a really cool language using this
same concept.  Instead of For Next it would just be a b.  THINK ABOUT
IT!

Bill Gates, move over!

While this has been entertaining, I think I've made the points I wanted
to make.  And yes, I can hear the huge sigh of relief coming from my
email client.

John W. Colby
www.ColbyConsulting.com 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Haslett,
Andrew
Sent: Wednesday, August 11, 2004 12:13 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Naming Conventions


Dunno what this II stuff you're going on about has to do with it - MS
never recommend that and nor would I.

My point is that you seem to recommend everyone using the same standard
and quotes MS as someone to take lead from when it comes to coding.
They've
*changed* their standard which pretty stuffs up your argument. 

And strongly typing IS a primary issue in naming conventions.
Intellisens is an added bonus. Here's 4 valid points of which
intellisense is only one.
http://www.fmsinc.com/dotnet/analyzer/Rules/Hungarian.htm

Its pretty clear that the generally accepted 'standards' are changing
for many reasons.  If people choose not to change with them - that's
their choice.  Many people refuse to accept others point of view and
will probably continue using outdated methods - just as they do coding
languages. And if they're happy with it then good on them, they may well
do the job for years to come and are the right tool for many
situations..

I'll say again, as long as *A* standard IS USED - and its clearly
documented and followed - then the rest of this argument is pointless.
Think of all the beautifully structured, commented and named code you
could have written instead of contributing to this thread  ;=) 
 


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



More information about the AccessD mailing list