Variable Naming Conventions
In most cases, you can name a variable whatever you wish. You can call it a,b,c or you can call it myVariable ... it really does not matter. This being the case, it makes good sense to use a variable that might actually help you to understand the code you have just written. If your code creates an object, then use a prefix that will let you know the variable contains an object. Then if you get a type violation, it will be easier to troubleshoot. See Table D-1 for variable naming standards.
Table D-1. Variable Naming StandardsPrefix | Sample | Use |
---|
obj | objFSO | Contains an object | int | intCount | Contains an integer | str | strName | Contains a string | bln | blnEnabled | Contains a Boolean value | ary | aryUsers | Contains an array | col | colItems | Contains a collection | sub | subLoggging | The name of a subroutine | fun | funLine | The name of a function | dtm | dtmLastAccessed | Contains a date |
If we expand upon this naming convention, we can arrive at a select number of common variables that would be used in the vast majority of scripts we write for use in the enterprise. Doing so will greatly simplify the reading and the adapting of scripts produced in the same organization. Consider Table D-2:
Table D-2. Standard VariablesVariable | Meaning | How Created |
---|
objFSO | The file system object | scripting.filesystemobject | objFolder | Folder object | objFSO.GetFolder | colFiles | Collection of files | objFolder.files | objFile | File object | For each objFile in colFiles | objShell | WshShell object | WScript.shell | objNetwork | WshNetwork object | WScript.network | objWMIservice | SwbemServices object | winmgmts:\\ | dtmTime | Date variant | Contains a time stamp |
|