Hungarian (Leszynski/Reddick) Naming Conventions (1 Viewer)

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.

I wonder if the Leszynski Naming Convention has reached its use-by date. I tend to strip it out of code that I import into my ms-access projects as even though being a native English speaker, reading code with tags is harder than reading code without. Other programming languages do not use this convention. This is my take on ms-access naming conventions.

LNC is usually promoted for improving code readability between developers and the host of other issues it solves and creates are never mentioned, so here is my list.

LNC benefits:

• Can be used to sort event procedures into order according to the type of control that the code hangs from. E.g. all combo box code is grouped together;
• Helps identify the type of variable for variables that have been passed into a procedure by reference, for example an array filled with data is passed to a function by reference. In this case, the variable declaration is not in the current procedure and it can be hard to find.
• Prevent ms-access getting confused. If a field and a control and a variable all had the same name sometimes ms-access would get confused and the code would not work. This issue has gone away in ms-access 2007+ as far as I can tell. Fields now have to be referenced through the Me. Object whereas before any field in the forms recordsource could be referenced directly e.g. Customer = “Frank” instead of Me.Customer = “Frank”.
• I also often felt that ms-access had issues with a lot of common words such as Tree, which have meanings in computer science as well as the real world. Many dozens of issues in my early coding career seem to be related to my choice of variable names which overlapped with computer science terms. LNC makes such naming collisions less likely.
• Prevents name collisions such as between a user defined type and a constant with the same name. Some of these will compile fine but then crash at runtime when the code is run, so represent a risk that can be hard to test for.

LNC cons:

• Makes code ugly and hard to read;
• Names bound and unbound controls in the same way;

I would like to confirm the validity of the cases for it placed in earlier posts. I use tbl in front of tables and qry in front of queries. The reason is that I often make complex queries and I like to use the base tables as input rather than other queries, so being able to tell queries from tables is useful. The prefix qry also indicates that the qry is referred to in code somewhere and is not an adhoc query that can be deleted. Similarly subform and forms are different. Usually opening a subform directly means that data entry and editing escapes the attention of any business rules provided by the parent form. This is very dangerous and I use code to force subforms to cancel on open if they are not opened as a subform within a parent form.

I would also confirm the general intent of the LNC, that is making it obvious what the item is for and what its data type is. With scalar (str, lng, dbl etc.) variables I rarely uses tags as the variable name can usually capture this information. E.g. CustomerName is a string, CustomerID is a long. In my code, I tend to only use Dates, Strings, Longs and Doubles so this simplifies the number of variable types I have to deal with. I do use LNC scope prefixes for identifying the scope of the variables g is useful prefix for global constants/variables and m for module level variables. Prefixes are however quite important for complex data types such as arrays, enumerations, classes and objects. Without a prefix it is difficult to know by looking at the base name that there are additional rules for accessing these types of data. These days I declare all complex data types in one list of dim statements and then declare all scalar variables in a separate list below. That makes it easy to find variables which need special rules.

Prefixes are also good on form and report controls. This is mainly because it is easy to sort procedures so that the procedures for a particular kind of control are grouped together. This make it easy to use the code from one control as a template for the code for another control of the same type or to refactor the code for all controls of the same type to pull out common functionality. I wish that LNC had a good notation for identifying unbound controls as the distinction is often important.

With method and function names, where I prefix these with a verb. A combobox for finding customers would be cboFindCustomer. Controls on forms are usually given a name that is very close or the same to the term displayed in the controls label.

So I happily live without the standard form of LNC and have found other methods of achieving the same intent that provide more readable code.

Reading mudsnakes post and reviewing my own, I would add that the prevention of naming collisions is important, (although l can't think of where this has caused me an issue, a sample db highlighting the issue would be good to have) particularly with "Date" often used as just that. A prefix of "dat" as in datDate is particularly ugly, so I often go for myDate or dobDate. The most important thing is to make your code easy to read and understand particularly useful when you return to it a few months later and can find yourself wondering what on earth was this guy doing? Unnerving when it's your own code! So a naming convention for me at any rate is casual, I only name the objects necessary to make the code human readable. I also have my own convention, for example I name a function:- fSQL_**** as it will take a parameter like a record number and return an SQL string.

fwiw, I always type my controls. I prefer grp to frm for instance, for an option group.

I tend to try and prefix field names in tables with a common prefix, so a "customer table would have fields beginning "cust" or "cus".

I never include a descriptive prefix for variables, although I do put them in a type container, to get some useful intellisense.

Note the (uppercase) T prefix for a type declaration!
I have never really used class modules for things like this, although it would be useful.

{and now I note this was an old thread}

Hi Dave, I've seen types but never felt the need to use them. After your comments here, I can see the advantage.

Because I work with the U.S. Government, I have to at least sometimes provide a convention-based naming system because of the concern over what happens if I leave. (Which is getting more likely as I get older because I am seriously preparing to retire within a couple of calendar quarters.)

I use tXXX for tables in my back-end, tlXXX for local/temporary tables that are in the front-end, tlcXXX for cache-tables.

I also use qtXXX for a single-table query pointing to the back-end, because in a previous version if you used the name of a linked table, it would always ask you where that table was located but if you defined the query for that table, it wouldn't ask. Never figured out if I was doing something wrong there but at this point the nomenclature is stuck.

My VBA code will prefix l for long, i for integer, s for string, d for double, and dtm for date/time variables. I don't use other data types that often, but I have a couple of data structures for which I use a prefix sometimes.

I prefer the naming convention to help me remember what some things are because I sometimes have to write pretty complex code and it would be easy to confuse myself in the middle of long code sequences. On the other hand, I'm not a slave to the conventions. In a subroutine where an object is to be passed in as a formal parameter, its type is part of the formal name - but in the call that invokes the routine, the actual parameter might not be prefixed.

I'll say this - the guys to whom this project will given all like the use of the conventions. They are worried about how they will maintain the code once I retire, so they encourage documentation and conventional naming as often and as much as possible.

After starting the thread, I found a recommendation to drop Hungarian notation on Code Review that came from a seriously good VBA developer. He provided a link to wikipedia.org/wiki/Hungarian_notation which lists the advantages and disadvantages of Hungarian notation. So going forwards, I will only use my version of LNC for identifying controls and for complex data types so that I know not to treat them as scalar variables. Finally, there is another factor. As it becomes possible to put VBA code under source control (see Rubberduck or /timabell/msaccess-vcs-integration at Github), this will result in refactoring of long procedures into a number of shorter procedures. Shorter procedures that do one thing are generally easier to understand and the need for LNC is reduced.