Use of a VBA naming convention. (1 Viewer)

ChrisO

Registered User.
Local time
Today, 13:17
Joined
Apr 30, 2003
Messages
3,202
Use of a VBA naming convention.

Discussion point.

One of the things I have noticed over the years is that it is virtually impossible to fully describe a fault in VBA by just using the English natural language. It may be possible in natural languages other than English, I don’t know.

When things are not simple, or obvious, we inevitably ask to see the code.

When we see the code, things may still not be obvious; the code may in itself not be obvious to the reader.

A consideration is that written code should not have to be dumbed down to the Sesame Street level. Any attempt to dumb down may be appropriate under some circumstance but some level of understanding is both assumed by the writer and required of the reader.

This then requires an assumption by the writer of some lower level limit of the reader to understand. If the writer does not make that assumption then the code continually blows out to an explanation of each and every word written in code. The code would then become an essay of the explanation of VBA words and not a VBA solution as a whole.

An experienced VBA writer would not want to explain each word, even if they could (it is extremely unlikely that they could), because it would distract the reader from the code. The code then becomes a compromise between not enough detail and too much.

To get an idea of this we can reverse the writer and reader…

Example of not enough detail for the reader…
Line of code:-
Discount = InitialPrice
That code could produce error 438: “Object doesn’t support this property or method.”
The above line of code does not suggest a reason for that error.


Example of a bit more detail for the reader…
Line of code:-
lblDiscount = txtInitialPrice
That code could produce error 438: “Object doesn’t support this property or method.”
The above line of code does suggest a reason for that error.
lblDiscount is, by naming convention, a Label and that Label needs to have its Caption Property specified.


Could we write it a different way so as not to use a naming convention? Of course we could, we can write the same code many different ways. But, by using a naming convention, we imply a small amount of detail at very little cost, in this case only three letters.

Without those three letters in that line of code we have nothing to go on. With those three letters we can start to resolve the problem.

To me then, a naming convention becomes a process of dumbing down our code to some predetermined level which we, as the writer, have determined as the lower limit of the reader of our code. That is not condescending, it is a practical limit placed upon our desire, and ability, to explain in detail.

But it remains entirely up to the writer which way, and by how far, they would prefer to go within VBA.

Chris.
 
I don't use that kind of naming convention in my projects. I don't like the way it associates objects that often have very little to do with each other. I see readability as a cost of the convention.

There are often other properties that are equally as important as the object type (eg bound or unbound) and I think choosing the object type above all others is really quite arbitrary.

Labels are a particularly good case to discuss. I name mine with the control they are associated with plus Label in CamelCase. eg DateEndLabel. This lists the label and the control together.

Similarly I prefer DateStart and DateEnd over StartDate and EndDate because they will list close together. The association in this case is more about the information they hold than the kind of control.

I have long said I would like to see Intellisense modified such that it will list controls when presented with a bang and properties and methods when a dot is typed. Microsoft has already done this in the Query designer of Access 2010.

When it comes to VBA variables I find naming conventions even less enticing. Hungarian notation made sense in vbs where the type was not declared but in VBA variable types are declared. Further information is readily available about variables with a right click. (QuickInfo and in particular, Definition can be useful.)

This is taken to the limit in VB.NET where the interface is pushing the information at the developer whenever they hover. Using Hungarian notation in VB.NET would be ludicrous.

However I do use the object and variable naming convention for posting code snippets where the information would not otherwise be clear.
 

Users who are viewing this thread

Back
Top Bottom