Naming procedures?

[terrypin]

I'm slow to the scene but am now beginning to make more use of the registry for convenient storage and recall. What conventions do others use about naming these please?

 

I've been fairly arbitrary so far, as in the following fragment:

 

Capture Control from Specific Coordinates into %NameCtrl%

Mouse Click on Control %NameCtrl%

Get Control Text from %NameCtrl% into %Name%

Write Registry Value "%Name%" into HKEY_CURRENT_USER\Terry\Text\MapName // Store in registry

Variable Modify String: Save %Name% to the clipboard

 

Quite often (if ME Pro would allow it) I'd be tempted to use the same text string. For example:

- the control is a box called Name

- the logical name for my variable is Name

- the logical name for the registry value is Name

 

I'm thinking maybe NameC (or C-Name) for the control, and plain Name for the variable and registry?

 

Any ideas, suggestions, pitfalls ... ?

 

--

Terry, East Grinstead, UK

[Yehnfikm8Gq]

With most of these things, once you get into it all becomes clear. Registry names can be what suits but descriptive and to the point is better. You will see from code in the forum that many people use prefixes for variable type eg Integer n or i. It depends on what computer languages you are used to. A single variable could be tVar, iVar, dVar, cVar depending on the format. Related to ME, that's simply an extension of T, N, C, D. A variable like %myunits% has to be renamed if it changes format from integer to text - with prefix %nMyunits%, %tMyunits%. A prefix is generally used more than a suffix.

[paul]

For registry names, there don't seem to be any naming standards that I've ever spotted. Given that you are not going to use these registry keys and values except from within your macros, I think the name immediately below the top level is the most important, so that you don't accidentally delete it and can easily remember what it signifies. Thus something like HKCU\TerryMEP\... is probably sufficient (and I'd exclude "Terry" if you're the only person doing this). Below that level, you might want to consider using "application" names (by which I mean a name describing which macro or set of macros), but probably only if you intend using many registry keys across a number of macros. Our PGM Library uses a section name "Professional Grade Macros", and subsections like Parameters, Pgm Functions, Swap, Variables, etc.

 

I also like to use naming standards for my variables; %t...% for text variables, %n...% for integers, %b...% for boolean, etc., followed by as meaningful a name as possible (but shorter rather than longer) using camel case, as in %tFirstName%. I think this makes the macro a little clearer, and I'm all in favour of "self-documenting" code rather than copious comments littered throughtout the code.

[terrypin]

Thanks both, appreciate those suggestions.

 

--

Terry, East Grinstead, UK

[Yehnfikm8Gq]

I definitely would not omit my name from the registry folder tree. If I don't use the registry regularly enough to remember where I put the goodies, I can usually remember my name or initials. Usually but not always! Registry editors usually have some form of bookmark or favorite list so it's not a big deal if you use those.

 

Most of us have fairly small projects. I've always made subsections by project title/abbreviation since I only have a few entries. The subdivision per Paul per PGM may be desirable for large projects.

 

I have to disagree with Paul's comment about self-documenting programs. There goes a programmer v user! My experience has been, without exception, that reviewing and using custom applications is a nightmare if undocumented properly. Looking back at the work posted by Floyd in this forum, it is so easy to follow what is going on. Writing a program in a logical fashion may help, but code is only "obvious" to the author. The companies I've worked for, you would get no return business relying on code to explain everything. It would be moot since proper documentation including commenting would be in the contract. You pay for it but it's worth the money. Some poor employee down the road is going to have to figure out how the program works.

[paul]

I have to disagree with Paul's comment about self-documenting programs. There goes a programmer v user! My experience has been, without exception, that reviewing and using custom applications is a nightmare if undocumented properly. Looking back at the work posted by Floyd in this forum, it is so easy to follow what is going on. Writing a program in a logical fashion may help, but code is only "obvious" to the author. The companies I've worked for, you would get no return business relying on code to explain everything. It would be moot since proper documentation including commenting would be in the contract. You pay for it but it's worth the money. Some poor employee down the road is going to have to figure out how the program works.

Sorry, I should have made the context clear. I was talking about documenting a macro for myself only. If documenting for other people, then I agree 100% with JohnS.