[AccessD] Naming Conventions

Then why has Microsoft CHANGED it's recommended naming conventions..

They recommend NOT to use prefixes now as its less relevant working in
strongly typed languages such as .Net.  Hungarian is out...
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcn7/html
/vaconVBNamingRules.asp)
(http://www.ssw.com.au/SSW/Standards/DeveloperDotNet/DotNetStandard_ObjectNa
ming.aspx)

Your argument about using the same naming conventions 'everywhere' so it us
universally recognised, is therefore mute. Microsoft THEMSELVES have
changed. Times change, technology changes, standards change.

The most important thing about using naming conventions is to actually use
one (as is usually the outcome of this religious argument). As long as its
documented as to WHAT convention you are using within a project, and you
stick to it, then those that follow have a reference.

In the real world, where you develop different projects with different
teams, in different companies, you're simply not going to always be able to
use the same convention. Therefore you need to be adaptable.

A



-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com] 
Sent: Wednesday, 11 August 2004 11:50 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Naming Conventions

Saving your time is nowhere near as relevant as saving the time of the
person coming in after you.  You put in 100 hours or 200 hours and are done.
The maintenance is hundreds or thousands of hours over many many years.  If
the poor schmuk coming in has to spend 100 hours just figuring out what the
heck your naming is before they can even do anything, the company just lost
all the money you saved them and MORE.  That person goes away and the next
person comes in and spends 100 hours figuring out your crazy naming
scheme...  That person goes away...  Hmm.... 

II?  GIVE ME A BREAK!!!

You are not focused on the overall picture, just your convenience and
"getting it out the door".  

I can tell you without a shadow of a doubt that if you went to a Microsoft,
or any other large company and told them "I want to program for you and this
is what I do and why" (giving them this email below) they would politely
show you the door.  

Using the fact that there is no "one standard" to justify doing whatever you
feel like is just silly.

John W. Colby
www.ColbyConsulting.com 

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


<JC>So what do I use for a counting byte?  Or a counting long?  The naming
convention I use (yes I realize that is I) has three character prefixes for
not only objects but data types as well.  Your point about "the whole world
doesn't program the same way" is of course valid.  But to program with the
convention I use I or J or K is NOT a valid variable?</JC>

That is exactly my point, that no one programs the same, which includes
'naming conventions'.  Since there is no truly established (and adhered too)
naming convention, anything works, and doesn't work, just as well/unwell.
And, you proved my point, 'to program with the convention I use', is just
like saying 'I like blue, so your red car is the wrong color'.  LOL.

Because there is no absolute standard, there is no way to program for those
that come after you.  YOU may like the code that you write, but the next guy
may use a different standard then you, and he will probably gripe just as
much about your convention as you do about someone elses.

To really write forward code, I (try to) stick to two rules.  One, stick
with the same naming convention throughout a project.  No matter what your
naming convention is, changing rules in mid stream is far more agitating
then just adjusting for a new convention.  Two, stick to the same
programming logic/style.

Personally, my pet peeve is goofy logic.  I honestly don't care what someone
uses as a naming convention, because I look at the logic the code is
running, rather then look at the names of the variables.  I have seen some
pretty bass ackwards logic in a lot of code.

Not too mention that existing Objects do not adhere to prefixed naming
conventions.  It's Me.Height, not Me.dblHeight.  Why?  Because Height is a
property, it's going to be a number.  When you look at someone's code, and
they refer to Me.Height, do you then go to the help, to find what data type
is used?  No, because quite frankly, data types are irrelevant until the
logic is satisfied.  If the logic works fine, you should already be familiar
with the variables in play.  Then it's only a matter of looking at the dim
statements to verify data types.  So when I create a Class, I use Properties
without prefixes, and I name the classes as to what they represent, without
a prefix.  It's not colForms("MyForm"), it's Forms("MyForm").  It's not Dim
rs AS objADODB.objRecordset, it's Dim rs AS ADODB.Recordset.  So if I build
an Class to represent an Inventory item, I would use Dim ii AS
InventoryItem.

Ack, wha?, spatter, spit, garble. That's right, Dim ii As InventoryItem.
Why? Because I code a LOT.  In VBA, VB, and ASP.  If I were to use:
objCurrentInventoryItem, that is 23 characters, versus TWO! I type around 80
words a minute, which is 400 characters a minute.  It would take me a minute
to type 17 of those variable names, versus typing ii 200 times!  That saves
time......by quite a bit.

Drew
--
_______________________________________________
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

IMPORTANT - PLEASE READ ******************** 
This email and any files transmitted with it are confidential and may 
contain information protected by law from disclosure. 
If you have received this message in error, please notify the sender 
immediately and delete this email from your system. 
No warranty is given that this email or files, if attached to this 
email, are free from computer viruses or other defects. They 
are provided on the basis the user assumes all responsibility for 
loss, damage or consequence resulting directly or indirectly from 
their use, whether caused by the negligence of the sender or not.