[AccessD] Naming Conventions

StaRKeY starkey at wanadoo.nl
Thu Aug 12 14:41:17 CDT 2004


:-) I get both points and isn't this thread just about who wants to be
right? 
I must agree with Drew that naming conventions wouldn't be necessary if we
all  knew our bussines a 100% BUT the fact is that prefixes do shorten the
time to figure out what variable is used sometimes thus making it faster to
bugfix for a lot of programmers.

But ohwell, to be honest I do not care too much about naming conventions
even if it makes code easier to read though commenting your code on the
other hand should always be done in my humble opinion since variables I have
usually figured out pretty fast but some colleague programming logic not!;-)


Cheers for the almost being weekend hehe 
Eric Starkenburg 

-----Oorspronkelijk bericht----- 
Van: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] Namens DWUTKA at marlow.com 
Verzonden: donderdag 12 augustus 2004 20:30 
Aan: accessd at databaseadvisors.com 
Onderwerp: RE: [AccessD] Naming Conventions 

No, I am implying that I am flexible, and 'you' (the 'we' camp) are not. 

Drew 

-----Original Message----- 
From: accessd-bounces at databaseadvisors.com 
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus 
Sent: Thursday, August 12, 2004 12:14 PM 
To: Access Developers discussion and problem solving 
Subject: RE: [AccessD] Naming Conventions 


<<...should be reconsidered sometimes. 

Maybe you should reconsider. 

Again you imply that we are wrong. We are only pointing out what is
considered a better way. 

-----Original Message----- 
From: accessd-bounces at databaseadvisors.com 
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of DWUTKA at marlow.com 
Sent: Thursday, August 12, 2004 12:48 PM 
To: accessd at databaseadvisors.com 
Subject: RE: [AccessD] Naming Conventions 


True, and a lot of the 'old time' scientistics, people that were in the
field for years, thought the world was flat. 

Hmmm, should we keep bringing up these kind of comparisons? 

Kodak balked at the idea of 'photo copies', because it didn't come close to
their current photography standards.....guess Xerox is living proof that
'our way, or the highway' should be reconsidered sometimes.

Drew 

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


>either way makes sense to me. 

And eating people made sense to Jeffry Dahmer.  The rest of society didn't
seem to agree. 

<grin> 

JWC 

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


Ah, but how does this: 

Dim objInventoryItem As InventoryItem 

make less mistakes then 

Dim ii As InventoryItem 

??? 

The 'argument' was that it makes it harder to read for a maintenance
programmer.  I really don't see that, because if I'm the maintenance
programmer, either way makes sense to me.  But I certainly don't see how
either method allows for less mistakes then the other, with the exception of
scripting, like with ASP.  In ASP, you are far more likely to misspell a
longer name, then a shorter name.

Drew 

-----Original Message----- 
From: accessd-bounces at databaseadvisors.com 
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Scott Marcus 
Sent: Thursday, August 12, 2004 10:37 AM 
To: Access Developers discussion and problem solving 
Subject: RE: [AccessD] Naming Conventions 


Drew, 

I've been waiting for you to say "bad practice". 

No one said you have a bad practice(even though I think it is and now I have
said it). We said it isn't "Best Practice".

You know, I could look both ways before crossing the street (considered best

practice) or I could squirrel method it(just dart across without looking). 
Either way, I get across the street. Now, not looking both ways may be the
quickest way across the road. If I get clipped by a car, it may or may not
be fatal. I can even get clipped by the car if I look both ways by using
poor judgment. I see a whole lot less dead people on the road than
squirrels.

My point is this... We all make programming mistakes even when using best
practices. These mistakes can be fatal (to your career or even someone's

life) or not. Why not choose a method that has been proven to help reduce
these mistakes? That is what naming conventions are all about.

BTW, I would never have a variable like 
strSomeVeryLongDrawOutOverlyComplexName. That defeats the purpose of the
naming convention. 

Instead of trying to punch holes in a naming convention, try using a naming
convention to see its benefits. 

Scott Marcus 

-----Original Message----- 
From: accessd-bounces at databaseadvisors.com 
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of DWUTKA at marlow.com 
Sent: Thursday, August 12, 2004 10: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 
-- 
_______________________________________________ 
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 



  _____  

avast! Antivirus <http://www.avast.com> : Uitgaande bericht is niet besmet. 


Virus Gegevensbestand (VPS): 0433-2, 10-08-2004
Getest op: 12-8-2004 21:41:16
avast! auteursrecht (c) 2000-2004 ALWIL Software.






More information about the AccessD mailing list