![]() ![]() It may save you days of stressful debugging. I urge you to try Denis St-Pierre's ByVal/ByRef test script to build an understanding of the concepts. Keep in mind that some day others may need to understand your code.Īgain, to be completely on the safe side, use ByVal as in Function MyFunc( ByVal varParameter ) You can choose any naming system you want. Using existing variable names for parameter names spells trouble. Though in VBScript any variable can contain any type of data at any time, this naming convention helps make clear what type of data a variable is supposed to contain.įor function or subroutine that receive parameters, use distinctive parameter names to avoid conflicts with global variables. You may have noticed that many scripters use the first character, or the first 3 characters, of variable names to specify the data type: objFSO for a (FileSystem) object, intDaysPerWeek for integers, etc. ![]() Imagine what a difference it will make when someone else needs to read and understand your code (or you yourself a couple of months from now.).īy choosing logical, descriptive names, you may also save yourself time while debugging. Or Decode instead of dec as a function name? However, instead of using a name like f, why not use objFSO for a FileSystem object? You are (almost) completely free to use any name for a variable, subroutine or function. Use descriptive names for variables, functions and subroutines To prevent changing the value of an existing global variable named varParameter in the global scope.Įxperiment with Denis St-Pierre's ByVal/ByRef test script to become familiar with the concepts. To be completely on the safe side, use ByVal as in Function MyFunc( ByVal varParameter ) If your function or subroutine receives parameters, use distinctive parameter names to avoid conflicts with global variables.ĭo not use an existing variable name for a parameter name.Īs you may have noticed, I use the prefix my for parameter names in my own scripts.Ĭhoose any naming system you want, but be consistent, and keep in mind that some day others may need to understand your code. If a "self-contained" subroutine or function has been debugged, it will save debugging time when you reuse it in another script. Modularize your scripts with functions and subroutinesĪny block of code that will be used more than once can be moved into a subroutine or function.ĭividing the code into logical subroutines and functions will improve readability of your script, and thus will make maintenance a lot easier. So "comment out" any On Error Resume Next lines while testing/debugging.Īnd whenever you really do need to use On Error Resume Next, check for errors ( If Err Then.), and switch back to On Error Goto 0 as soon as possible. When you're looking for the cause of an error, you do want to see the error messages stating which line in the code generates the error. (Temporarily) disable all On Error Resume Next lines It will also help you find variables with the wrong scope (local vs. It may seem a nuisance to force yourself to declare all variables, but trust me, Option Explicit will save you a lot of time searching for errors caused by typos in variable names. Make sure you log any requirements that aren't met, and/or display descriptive error messages.Īlways use Option Explicit and declare all variables Always check if required extensions are available before trying to use them!.If you create a new instance of an object, use custom error handling with Err and IsObject to check if it was successfully created.Never assume an open Internet connection.Never assume a script runs with administrative rights.See the paragraph " Test for 32-bit MSHTA.EXE on 64-bit Windows" below to see how you can test this in HTAs. Never even assume the script runs in a 64-bit environment when on 64-bit Windows! when third party COM objects or external commands are used). 64-bit), test in case it might be critical (i.e. Never assume Windows' "bittedness" (32-bit vs.This may be the most important thing to keep in mind when Test for 32-bit MSHTA.EXE on 64-bit Windows.Document your scripts with useful comments.Use a VBScript aware editor or IDE with built-in debugger.Display or log intermediate results like variable values and return codes.Use descriptive names for variables, functions and subroutines.Modularize your scripts with functions and subroutines.(Temporarily) disable all On Error Resume Next lines.Always use Option Explicit and declare all variables.This page describes some (debugging) techniques that will help you avoid errors in VBScript, or to find and correct them. Scripts will seldom be perfect right away. VBScript Scripting Techniques > Debugging Your Scripts Debugging Your Scripts VoltCraft Energy Logger 3500 Configuration. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |