JWColby
jwcolby at colbyconsulting.com
Thu Mar 15 11:59:36 CDT 2007
>Yes, John, but you go to extremes! ;-> LOL, as I said, it is all about making our own life easier and I find that these conventions make my life easier. 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 Charlotte Foust Sent: Thursday, March 15, 2007 11:37 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Naming Conventions Yes, John, but you go to extremes! ;-> Charlotte Foust -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby Sent: Thursday, March 15, 2007 8:12 AM To: 'Access Developers discussion and problem solving' 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 -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com