#NoEnv thoughts?

[JBensimon]

I just went through the tedious exercise of converting to #NoEnv a large script that relies on user configuration and input that in most cases involves multiple unpredictable environment variable references. This among other things required replacing uses of Transform, OutVar, Deref, String with a Deref(String) custom function that invokes the ExpandEnvironmentStrings API function.

But now, finding myself uncertain that I truly caught every possible environment variable reference in the script itself and that I took into account every possible way that the program's user configuration and inputs might include environment variable references, I ask myself: have I really done anything to improve the script's performance? To be clear, I never use uninitialized AutoHotkey variables, and I never use unquoted type parameters in DllCall (which always struck me as poor syntax).

I'm very tempted to go back to the way things were without #NoEnv, for peace of mind. Any thoughts on the matter?

Thanks.

[mikeyww]

Since it's recommended for new scripts, I probably would not make special efforts to regress.

[just me]

I don't recommend to run scripts without #NoEnv because of

Code: Select all

; uninitialized
MsgBox, %Temp%
; set to "Temp"
Temp := "Temp"
MsgBox, %Temp%
; reset to ""
Temp := ""
MsgBox, %Temp%

Also, you cannot know which variables might be defined in the environment of a special system.

[JBensimon]

My thinking is that since I never reference uninitialized variables (I don't just assume variables start blank), there's never a chance that a reference will accidentally match an environment variable: every reference is either to an "internal" variable I've set (which AutoHotkey will resolve immediately without having to consider environment strings) or it's a deliberate environment variable reference (which I use in the absence of an AutoHotkey equivalent, like for example UserProfile), in which case AutoHotkey will resolve it from the environment as I intended. I thus avoid having to use EnvGet for every variable that I know I'll need, and more importantly, I don't have to invoke the ExpandEnvironmentStrings API function obsessively whenever there's the possibility that variables were used in user-provided strings.