Quote:

I believe the explict option has something to do with memory allocation but not really sure.



Where did you get that idea? Explicit has nothing to do with memory. It is a flag to tell the interpreter that if it encounters an undeclared variable it should be treated as an error. By default when the interpreter encounters an undeclared variable it will simple create it and continue.

As one of the most common errors (and one of the hardest to track down) is spelling errors in variable names setting Explicit on means that you will catch these errors very quickly, which is why it is considered good practice.

Quote:

[RE: NoVarsInStrings] Just trying to understand the logic. I figure I am missing something. Is there a better way to set these variables?



I think you are just misunderstanding the intent of the command. It is not to avoid having variable values in strings, it is to avoid having variables in strings when what you want is the value.

Code:

; BAD! Variables in strings:
$USERPROFILE = EXPANDENVIRONMENTVARS(READVALUE("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\@SID","ProfileImagePath"))
 
; GOOD! Variables not in strings:
$USERPROFILE = EXPANDENVIRONMENTVARS(READVALUE("HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\"+@SID,"ProfileImagePath"))


There are a lot of good reasons why you should avoid variables in strings, but this simple example should do:
Code:
"Value of variable $$FOO is '$FOO'" ?
"Value of variable $$BAR is '"+$BAR+"'" ?


If you run this example you will see immediately why variables in strings can cause problems.

Quote:

I also created the following variable,
$MY_DOCUMENTS = EXPANDENVIRONMENTVARS(READVALUE("HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders", "Personal"))



This second piece of code is fine as the intention is that the variable name is in the string, not the value. This is so that the expansion of the variable value can be deferred, such as when you use the ExpandEnvironmentVars() function.

NoVarsInStrings and Explict are considered good practice because they will make your code more reliable.

If you ever intend to submit code to the UDF forum it is a posting requirement that the code must be able to work in with NoVarsInStrings and Explicit switched ON.