Be warned. I am jumping up on a soapbox!!!!!!!   :-)

I normally work on Access projects on my own. The projects are usually small enough that a single developer can do the work in the required timeframe. It saves time as no co-ordination needs to occur.

There are various ways in which I have worked with other developers.

• I have taken over work that another developer had started
• I have been on projects where there was another developer on site working with me
• I have sub-contracted some of the forms for a project to a junior developer
• I have been a sub-contractor to another developer
• I have helped another developer take over a project from me
• I have shared ideas and code with others via the internet or even in person

After all these experiences what advice do I have?

The very first one that comes to mind is CONSISTENCY OF STYLES.

What do I mean by "consistency of styles"? Several thoughts come to mind.

• naming standards
• look and feel of forms
• VBA coding

On a recent project that I took over from another developer (and there had been at least one other before that!) there were two main tables. They were very similar in structure, but needed to be kept separate. One was called "Fruit" and the other was called "Main Vegetables Table". See what I mean about naming standards? If one is called "Main Vegetables Table", let's call the other "Main Fruit Table". The purposes are similar, so let's make the names similar. (the table names were changed to protect the guilty!)

On another project that I took over (always consider the person who will take over from you some day - don't be that person who says to themselves "Why should I think about them? No one cared about me." That is not the way life is to be lived. But that's another soapbox issue and I don't have time for that here!) one form had a very nicely done look, with a subtle graphics design. Another form had what I call the standard battleship gray background.

DO NOT name fields with spaces or special symbols. "ID #" looks cute, but you will be dealing with that space forever. In many cases, a space means you must refer to the field like this

    [ID #]

and after a while, having to always include those square brackets gets to be a pain.

This look and feel idea goes beyond background colours and other graphical elements. For example, combo boxes and list boxes can be used in similar ways. Do you have standard conditions under which you will use one over the other? If you have 2 parts of your project where you present custom search capabilities, are they done in a similar way? If you allow the use of keyboard shortcuts, either Alt key combinations or function key use, are you consistent? Does F12 always mean "close current form" or does it mean that on one form and something totally different on another form?

What about dates? Do you always show them on forms and reports in a standard and unambiguous way? I always show dates similar to the style Feb 3, 2003 as opposed to 02/03/2003 (or should it be 03/02/2003?)

If you are using Bound Forms, do you make the Name of the text box the same as the name of its control source? That is, if you have a field in a table called DateOfBirth, is the text box on the form also called DateOfBirth? Or, if you do not like that style, do you at least call it dtmDateOfBirth? I have seen forms where the name of the object is text49, etc. In the VBA code do you realize how confusing this is?

Here is a real life example of naming that I found on a project I inherited.

   field name from table : Date Closed
   text box name on form : TxtIssueResolveDate

Okay, yes, Resolve and Closed are similar in meaning, but ...

How about your VBA coding? Do you always use "Option Explicit"? I urge you to. Do you use indenting on IF and WHILE code chunks? Makes it easier to read. Do you declare and use your recordsets in a similar way each time? If you will be refering to an object in the VBA code, then PLEASE give that object a meaningful name. INCLUDING labels.

   if text38 = "ABC" then label4.caption="Beginner"

How easy is that to read? Compare the following.

   if txtEducationCode = "ABC" then _
      lblEducationLevel.caption="Beginner"

Much easier.

When naming objects or declaring local variables, use Camel Case. Camels have humps. Your names should as well.

   not       txteducationlevel
   rather    txtEducationLevel

It is easier to read AND as you type, you can type in all lower case and errors will be spotted. When you leave that line of code, Access puts in the appropriate upper case characters and your eye slowly becomes trained to see the change. If it does not see the change of case, then it signals the brain, "must be a typo in there".

Happy Coding

 
Note: This web site dedicated to MS Access database users is an independent publication of Richard W. Killey and is not affiliated with, nor has it been authorized, sponsored, or otherwise approved by Microsoft® Corporation.
 

© 2006, 2007, 2008 Richard W. Killey. All Rights Reserved. - Privacy Policy