[AccessD] Naming Conventions

DWUTKA at marlow.com DWUTKA at marlow.com
Wed Aug 11 16:14:01 CDT 2004


<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



More information about the AccessD mailing list