Thanks again for the kind words.
Coding style has four principal elements:
1. Formatting conventions
2. Naming conventions
3. Commenting
4. Organizational preferences
From previous discussions on the mailing list, I know not everybody is fond of my coding style, and the naming conventions seem to be the most disagreeable. After 40+ years of programming, you might wonder why somebody finds it really useful to use readable explicit names that can be traced across many files with prefixing the lets you know at a glance where the variable was defined.
Curse Hungarian prefixing, it sucks. Ugliest code recipe ever. The type is a lot more discernible from context than the locus (where it is defined), so less utilitarian as well.
Some people prefer cryptic variables names. I understand that. I use them also for local variables where the definition is never far away.
If you're up for a challenge, I would recommend adding a button on the upper right which reads the word list and generates a text file with two columns. The first is every variable name instance you find with my naming convention. The second is an automatically name mangled cryptic version derived by some rule from the first. Then add a second button which reads this file, then loops through all the files, and for every occurrence of a variable name instance, replaces it with the new alternative.
This will let you push the first button, edit the text file for tweaking, apply the name changes. Done properly, it should be "provably correct" so you won't introduce any bugs.
One rule might be to scan the variable name for capital letters, convert them to lower case and make that the name. Your program needs to ensure that you don't produce the same replacement name for two different variable names. Another rule might simply be to strip the prefix. If you're a Hungarian fan, you should be able to find the variable definitions (quasi-compiling) and prepend type identifiers to the variable names. Good luck coming up with an agreeable list of prefixes for that.
If you do this, please post it as a reply as I suspect there are other people who would find that useful as well. They want to use my code, but the naming convention clashes with their coding style so ....
My prefixes are easy to spot mechanically. They are:
Code: Select all
My = Public property
my = Private property
Our = Static public property
our = Static private poperty
The = Form control (externally public or not)
the = Local variable
Arg = Calling argument in public method value is read only
arg = Calling argument in private method value is read only
Ret = Calling argument in public method value is return only
ret = Calling argument in private method value is return only
Mod = Calling argument in public method value is modified
mod = Calling argument in private method value is modified
Names that are part of structs don't get prefixes. They are never used stand alone and the locus is determined by the struct.
Here is a line of code:
TheFileGridView[r, 5].Text = Str(theFileHolder.MyLineCount)
Here's what I can tell just from the naming:
"TheFileGridView" is a GridView control on the form. "theFileHolder" is some sort of object or struct. I know it is an object because of the "My" on its member. (A "my" would be an error check in this case as it is supposed to be private and not accessible) It is either a "Holder" object for "File" instance, or it is the sole FileHolder in that routine. In this case, the latter.
Any doubt what "LineCount" means? Would "lc" be preferable? Or "nLines"?
Finally, consider if you had a verbally interactive IDE, and you want the code mechanically read to you, which naming convention do you think would work best?
Read these out loud:
"The file grid view element r comma five dot text equals string function of the file holder dot my line count."
Corresponding Hungarian:
gvFile[r, 5].Text = Str(oFileHolder.nLines)
"g v file element r comma five dot text equals string function of o file holder dot n lines"
Readability enhance comprehensibility. The readability of something is highly dependent on the reader, so the style you are used to is the one you will find more readable. Funny how that works.