How much use do you make of Leszynski/Reddick naming conventions in your designs?

I have never been a big fan, particularly for objects such as tables, queries and forms. I don't know the details of their original concepts but, unsurprisingly, they parted ways through disagreement on the details, no doubt becausr it is an entirely arbitrary connvention.

Some developers seem to use it to a limited extent while others take it to ridiculous extremes using such things as fldSomeName for fields in tables.

In most cases the context makes the type of object clear or it doens't particularly matter. Aside from fld, a couple of others spring to mind that I particularly eschew.

A Select query and a Table are almost indistinguishable when used as a data source. So why distinguish them with a prefix notation like tbl and qry that disassociates such queries from their tables and groups them with other queries they have nothing in common with?

Access demonstrates the interchangability of tables and queries both within query design and by the fact that a table and a query cannot have the same name while allowing a query or table name to be reused for a form.

There is no intrinsic difference between a mainform and a subform object so why prefix with something like frm and sfrm? Indeed the same form can sometimes be used both as a main form and a subform depending on the context. Besides it is invariably referred to as subformcontrolname.Form when used as a subformcontrol's source object.

Parts of a form may have different control types all associated the same kind of information. For example DateStart, DateEnd, DateRange. Logically they are more stongly associated with each other using the same starting characters where as with Hungarian notation they could be widely separated with prefixes like cbo and txt.

I can see some occasional advantage when using Intellisense and one can't remember a controlname at all or locate it among the dozens of properties in the list. However good naming of the controls will usually suffice to remember how the required contolname starts.

While on the subject of Intellisense, it is a pity it does not separate objects and properties in the prompt list. A checkbox filter in the header of the list would do.

However it would be far more fluent if it could distinguish the bang. Hit the Bang to get the object list and the dot for properties. That would even help new devolopers understand the difference between a dot and a bang.

I think a naming convention is used to more clearly describe a name.
I also think the system breaks down if someone has to carry a dictionary to explain the naming convention.
KISS.

To me, a select query is an ordered, filtered sub set of the table it is based on. The query is not the table and its name should be prefixed to make that distinction.

A form is not the same as a sub-form in general usage. A sub-form can sometimes be opened as a standalone form but they usually need to be designed that way. A sub-form, when opened standalone, is not the same as a sub-form ‘opened’ in a sub-form control. A sub-form opened standalone is open and is in the Forms collection. A sub-form ‘opened’ in a sub-form control is not opened at all and does not appear in the Forms collection. In a sub-form control ‘the’ form is never opened but rather an instance of that form is ‘opened’. They are not the same thing but I do not use a naming convention to distinguish the difference. I also doubt if there is a naming convention to distinguish the difference and I would not use it if there was. All instances of sub-forms, in a sub-form control are identical in structure and only vary at runtime due to their properties. It would seem logical that if all instances are identical then they should have the same naming convention. But if all instances of the same sub-form can behave differently, due to their properties, then the difference between them should be reflected in a change of their name at runtime. That would seem to be illogical so I wouldn’t use it even if I could.

I think the reason Intellisense does it that way is because objects and properties are not clearly defined. Objects can become properties of the form/report, and that remains an arbitrary decision of Microsoft. Intellisense behaves the way Microsoft wants it to because Microsoft wrote it that way. (Weak anthropic theory.) To me, VBA is not meant to be a strict language but quit to the contrary by design. Imposing arbitrary decisions on VBA seems counter productive to me. It might be a property, it might be an object, but why make the distinction? The distinction may confuse so why inject confusion into a product designed for users, not just programmers? VBA is different and I think it does a brilliant job of demonstrating and applying that difference.

Chris.

Thanks for your perspective Chris.

While I can see the point about the difference between a table and a query I consider the data relationship between them more important. Consequently I tend to start their name the same and define the difference later in the name.

Having said that I often put the query text into the Form's RecordSource property so I don't have a lot of naked queries showing.

It also occurred to me that a developer's naming convention could be affected by the way they use the Navigation Pane View. Someone using Tables and Related View might be be content with that grouping and care little that the related objects had wildly different names in different groups.

I find the naming convention very helpful, I don’t use it religiously, and by this I mean I don’t use it all the time (within the same project), just on the most common objects. I have my own version of it, based on the original with minor adjustments which suit me.

The most useful place to use a naming convention is for controls on a form, so for instance when you are writing code in the form module you may write Me.**** And you can quickly and easily find with intelesense the textbox or combo box you are looking for because it will be prefixed with either txt or cbo, why would you not want this convenience?

Sub-form windows are a nightmare if you leave them at the default name that Microsoft provides, I always change their name as soon as possible and prefix them like this: subFrmWin****** again, makes them very easy to find when you are writing your code.

As for functions and subroutines, I always prefix them with “f” as in fMyFunction or fMySub.....

I always write a function when I am coding, I never write a subroutine, and when the project is finished I will usually go back through and change any functions to subroutines where possible, but it’s not a religious operation and it does not worry me if there is a function where a subroutine could have been used.

I never worry about the “bang” I never use it, I favour the “.” In all places. There has been much controversy over its use in the past and I have seen nothing that convinces me that it is necessary to make a distinction.