I use my own VBA naming "convention"

[keviny04]

I've been developing in Access for over 10 years and I've never used any of those de facto variable naming conventions like Reddick, Leszynski, etc. I was introduced to them very early on, but didn't really fancy using them. To me, they add excessive nomenclatures that add a lot of "noise" to the code. So I went on my own way from then.

The only naming scheme I would consider carefully is the naming of table field names, but that really belongs under database design, not variable naming. My scheme here is what most people would use: no reserved words, no spaces, avoid duplicate names even among different tables, etc.

Especially important to me is distinctive field names. E.g. A table of billing addresses and a table of shipping addresses should have DIFFERENT field names from one another, even though both tables have same type of data: street address, city, state, etc. To me, same "type" doesn't mean the same. I use identical field names only when two fields are TRULY the same. E.g. CustBillTo table has CustID, CustBillToName, CustBillToStreetAddr, etc., and CustShipTo table has CustID, CustShipToID, CustShipToName, CustShipToStreetAddr, etc. In this case, the CustID field is TRULY the same in purpose and content in both tables, so I would name them identically.

But most of the times, distinctive field names are preferred, otherwise it could mean big trouble. For instance, if you join the CustBillTo and CustShipTo tables in a query, and if both tables named its address fields the same way, i.e. StreetAddress, City, State, etc., you would have conflicts of column names in the query. And you end up having to rename the columns in your SQL anyway. E.g. SELECT CustShipTo.StreetAddress as CustShipToStreetAddr, etc. So the naming of table fields is paramount.

But in naming other things, such as forms, queries, modules, tables, VBA variables, etc., my "convention" is simply anything goes. Anything that is descriptive enough and understandable enough. Can have spaces. Can use plain English. Can be long names. Can have special characters like colons and dashes. Can be all uppercase, all lower case, or capitalized. Whatever convention there is is loose: a form's name has the word "form" somewhere in it; a command button's name has "btn" as its suffix, etc. E.g. "Customer subform", "CUSTOMER MAIN FORM", "Query: active customers". More important for me is that I am CONSISTENT in how I name them, and I think that is true in all naming schemes. I put the most restriction on procedure names, such as no spaces nor special characters, but that's only because VBA restricts them.

I know I'm an abject minority, and almost all books I've read on VBA always mention the need of naming conventions, especially the de facto ones. But the other day, I was reading "Beginning ASP.NET 4.5 in C# and VB" by Imaar Spaanjaars and to my surprise and amusement, the author not only doesn't really endorse using naming conventions, but also writes what seems like a knock to such a practice:

Page 202:

PRACTICAL TIPS ON PROGRAMMING


The following list presents some practical tips on programming: Always give your variables meaningful names. For simple loop counters you can use i, although loopCount probably describes the purpose of the variable much better. Don’t prefix variables with the word var. All variables are variables, so adding var only adds noise to your code. Consider useful names such as _firstName and _categoryId as opposed to strFName, varFirstName, or catI for private fields, and names like FirstName and Person for public properties and classes, respectively.

[ItsMe]

Consistency is paramount. I use naming conventions in VBA and I want to know a query is a query, a table is a table, etc. So my names look like qryMain, tblMain, etc. In other programming languages, you will see very long and descriptive names and there will not be a naming convention that adds a description to the front of the name. This has changed from how it used to be. Newer computers and systems allow for longer names and newer IDE's have more robust Intellisense that describe exactly what the object is.

I am not a naming convention expert but the way I understand upper and lower case conventions is upper is for Public and lower is for Private. So, a Public Class Name is upper case and a Private Class, field, etc is lower case. I would expect to see this (Pascal) in C#. Other languages may differ. In Access, I use (CamelCase) to make things readable. I will use the object description (qry) in lower case and the rest in upper tblImportantRecords.

[orange]

I think that we all use our own version of a naming convention, and as ItsMe says --consistency is key.
If you are a lone developer, then you will use something that will become more consistent as the number of databases/applications etc increases. Many will develop patterns or names in a more and more consistent manner.
However, if you work in a large organization where there may be several designers and developers, and even contracted analysts, designers, developers, and have several concurrent projects -- with review and sign off authorities --naming standards, documentation standards, testing scenarios, user training etc become quite important.

When you find yourself in a brand new organization/company/department which has merged several other groups/organizations and the focus from management is better information and data management practices, its a whole new game. Enterprise models, conceptual models, subject area models.... names and definitions of "things" and "processes" take on a new importance that can not be left to individual whims and choices. There is a lot more discipline required and the approach must be "monitored" for overall effectiveness. And it requires constant communication and training/retraining. Just as with finance where you want to know spending patterns, what funds are available by organization, program/envelop, fiscal year.... there is a need to know what information we have, where it is, who/what interfaces with it; what format is it in/available.....

Many posts here on the forum (and others) are from individuals often just beginning with a database project. Their scope and design approach is not well defined. They struggle with Access tools/objects and syntax often with no appreciation of database concepts. Not all are like that, but many. So advising posters to adopt a naming convention that will reduce syntax errors is a positive comment. If they follow some existing schemes/suggestions (Reddick, Leszynski..) so be it, if they make up their own that's working for them --great. But when you see a poster with say 50 posts and the code sample is full of Phone#, ID, Field3, Field124, Company Or Person Name... it's time to suggest some alternatives.

All this to say naming is important; consistency is important; understanding the environment in which the database/application will operate is important; documentation is important; design is important; keeping users involved as development stages are reached is important; interfaces with the database is important; resolving issues early is important; testing is important....

[Micron]

[Don’t prefix variables with the word var]
If I use var, it's because to me it means variant, not variable. Not sure if I've adapted the original meaning or if the advocate of that statement is misinformed.

[a Public Class Name is upper case and a Private Class, field, etc is lower case.]
ItsMe, can you give examples? I'm not sure if you mean the name of the class object or the attributes/properties etc.
Thanks.

[ItsMe]

...ItsMe, can you give examples? ...

It is difficult to give examples in Access because so much of it is around Private classes. If you are working in a form's Module you are working in a private class. All code within the module is private to the form. This is what I have been taught and there may be a way to pierce the module. But, for the sake of this explanation let's consider this to be how things really are.

If a form's module is Private and a Standard Module is Public, then you would not be able to place a (truly) Public Function within a form's module. If you create a Function within a Form's Module, it will be private. If you create a Public Function within a Standard Module, that function will be available on the Public Interface.

If you create a Private Sub or Private Function within a Standard Module, it will not be available via the Public Interface. They will be private to the Standard Module.

If you make declarations in a Standard Module's header, those dimensions will be on the Public Interface. If you make declarations within a Form's Module, they will be Private, regardless if they are in the header or in a Function/Sub routine.

So, now to the naming convention ...

In a Form's Module
Dim strMyString as String
Dim lngMyID as Long

compared to a Standard Module's header
Dim MyString as String
Dim MyID as Long

[CJ_London]

there may be a way to pierce the module

you can, by changing Private to Public - even standard functions such as Private Sub Form_Load() can be renamed Public Sub Form_Load() to be available outside of the form, but with the proviso that the form has to be open or an error will occur. This can be useful if you want to run some code in a subform from the main form or another subform or vice versa but I wouldn't advise it to run code in a completely separate form.

[ItsMe]

you can, by changing Private to Public....

Yeah, in the back of my mind I thought I recalled it being possible. Just trying to explain the difference between the Private and public interface. Not easy to do with Access. I even ran into a wall with my example using variables. Had to drop the Hungarian notation just to stay with the Pascal for Public theory.

[Micron]

I was aware of the scope of procedures and declarations that you wrote about. I just didn't understand your remark about differing the notation between them. With respect to your Dim statements, I'm not sure I see the reason for the difference. I learned to notate everything the same, keeping in mind the scope of a procedure or variable, depending on the use of Public and Private statements where applicable, and whether or not Dim'd variables were in what I learned is the declarations section (what I think you're calling a header) or the code section. So for me, it is lngSomething regardless of where it is declared. Not saying one way is better than the other, and I thank you for taking the time to explain.

However, I did not know that you could call a procedure in an open form/report module from another form if it was declared Public as Ajax says. I thought the form module was private regardless of how you defined the scope. That's interesting.

[CJ_London]

That's interesting

It has it's uses. If within that function/sub you are referring to the me collection it refers to the current instance. So for example if you have a form used as a subform (called say sfmA) with trhe load event made public and it is used in a form where there are two (or more) subform controls (called sfCtl1 and sfCtl2) both with sfmA as the source object

a call to sfCtl1.form.Form_Load will only use the me collection within the sfCtl1 instance

[Micron]

Now you have to explain why you would put form sfmA in two different subform controls! I would never have thought to do anything other than have sfmA in sfCtl1 and sfrmB in sfCtl2 and let the load events run automatically as they do?

[ItsMe]

...I just didn't understand your remark about differing the notation between them...

I created the long explanation to try and draw a parallel in Access. As noted, the explanation failed when I got to public variables. Most Access users use Hungarian notation as a convention, myself included. So, it may be best to define public variables as glngMyLongInteger, etc.

[CJ_London]

I would never have thought to do anything other than have sfmA in sfCtl1 and sfrmB in sfCtl2

An example would be aircraft maintenance. The aircraft has 1,2,3 or 4 engines and you want to be able to see the specs/performance info for each engine.

You could do this with a crosstab query but the user required each engine detail to be independently scrollable and filterable (there were some 50+ elements). So 4 subforms, one for each engine (where there were fewer engines, subforms here hidden and the visible ones respaced across the screen. Each subform form is identical - so why would you want to create 4 identical forms?

With regards events, I was just using form_load as an example - perhaps you have code there which for some reason you need to run again without closing and reopening the form. I don't normally change the 'standard' functions to public (I was just pointing out that you can) but may have other functions - perhaps to do with form layout which need to be run from a parent or co-subform. The code is specific to the form and for ease of maintenance I would rather keep it there than pass the form collection to a sub or function in a standard module - or put it in the main form and referencing the subform.form.

[Micron]

Well, if it works, why not? I probably would never have thought of doing it that way, but you are right to want to minimize code and design objects as much as possible. Thanks for the tips.

[IrogSinta]

Like Ajax, I'm a proponent of using the same form or report multiple times as subforms or subreports. For instance, I have scheduling form with 7 subforms, one for each day of the week, but it's really the same subform inserted 7 times in the main form. I also have reports with 5 columns showing metrics for the past 5 weeks, and again it's the same subreport inserted 5 times.

Calling a procedure or function on a main form from a subform (or vice versa) is practical. It's better than having the same code repeated in different places. If you need to make a change in 1, you would have to find all the places that use the same code and make the change there too.

Just my 2 cents :-)