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.
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.