[AccessD] Naming Conventions

Thanks for all the info.  I have always used the "standard" tags and 
prefixes (i.e., "tbl", "frm", cbo, etc.) but figured it was time to become 
more descriptive!

John C. --- thanks for your explanation of prefixes....I am currently 
learning about classes from the information on your website :-)

Thanks!
Barb Ryan

----- Original Message ----- 
From: "JWColby" <jwcolby at colbyconsulting.com>
To: "'Access Developers discussion and problem solving'" 
<accessd at databaseadvisors.com>
Sent: Thursday, March 15, 2007 11:12 AM
Subject: Re: [AccessD] Naming Conventions


> As for prefixes to the prefixes, I use:
>
> g for (G)lobal
> m for (M)odule level global
> l for (L)ocal level (inside of a function)
> F for (F)orm level global
>
>
> In the last two years or so I have also taken to prefixing my functions 
> and
> subs IN CLASSES with:
>
> p for (P)roperty
> m for (M)ethod
> c for (C)lass (returns a pointer to a class or other object
>
> So for example I would write
>
> Property get pMyProperty() as string
>
> Function mMyFunction() as integer
>
> Function cMyClass() as clsMyClass
>
> I do this so that the functions sort into groups and I can tell at a 
> glance
> what they do.  For example a cMyClass() is going to have to use the set
> statement:
>
> set lclsSomeObject = mclsMyClass.cSomeClassOrObject
>
> Once you get to the level of using classes, it is frequent that you will
> have collections (or other objects) dimensioned in the class header. 
> "Best
> Practice" conventions say you should not expose the pointer to the objects
> in a header directly - to prevent other processes from accidentally 
> setting
> the pointer to nothing - but rather to use a function to get and return 
> the
> pointer.  Thus in the header of a class (or module for that matter) you
> might have:
>
> Private mcolMyClassInstances as collection
>
> Function cColMyClassInstances() as collection
> set cColMyClassInstances = mcolMyClassInstances
> End function
>
> This allows your class to dimension the collection private and never 
> allows
> any other object EXCEPT your class to mess with the pointer to the
> collection (set it to null for example), but does allow other objects to 
> get
> at it in order to manipulate the collection.
>
> As always, naming conventions are a tool to help YOU do your job a little
> easier and faster.  What you will find with any convention is that it is
> hard to get started with but once learned becomes automatic.  It is just a
> matter of using it until using it passes over the hump and becomes
> automatic.  And as stated elsewhere, it is not so much what you use but
> rather that you use it consistently.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Dan Waters
> Sent: Thursday, March 15, 2007 10:39 AM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] Naming Conventions
>
> Barb,
>
> I looked through the official list which Bryan listed (Thanks Bryan!), and
> found that I use three exceptions:
>
> 1) Instead of str as the prefix for a string variable, I use stg.  Str is 
> a
> VBA key word!
>
> 2) Instead of cmd for a command button, I use but.  I need obviousness!
>
> 3) For scope variables, I capitalize the M or the G.  It's easier to see 
> in
> code.
>
> Dan
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan
> Sent: Thursday, March 15, 2007 8:54 AM
> To: Access List
> Subject: [AccessD] Naming Conventions
>
> Is there a "gold standard" for Access/VB naming conventions?  I've been
> looking at Reddick's (1994).
>
> Also, I am having difficulty understanding how to use prefixes with 
> tags ---
> e.g., cls= a generic class; mcls=class defined in a module??; fmcls=???
> Any suggestions on where to look for clarification?
>
> Thanks,
> Barb Ryan
>
> --
> 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