AutoIt Wiki - User contributions [en]

UDF-spec

2014-08-05T06:37:32Z

Jpm: /* Naming */

[[Category:UDF]]
{{WIP}}This page is still under construction.

----

A library is a collection of one or more User Defined Functions (UDFs). However, the term UDF is often used to describe the collection as a whole. If a UDF is to be considered for inclusion in the standard set distributed with AutoIt then it must meet all the criteria detailed here, but it's also good practice to always write in conformance with at least the majority of this document, as that is what will be expected by people reading your code later.

== Basic Requirements ==
Firstly, the code itself should meet the following basic requirements:

* Be tidied. Just hit <code>Ctrl+T</code> from SciTE or run Tidy manually. The only flag needed is <code>/sf</code>.
* Pass Au3Check with no errors using the strictest settings: <code>-q -d -w 1 -w 2 -w 3 -w- 4 -w 5 -w 6 -w- 7</code>
* Support everything AutoIt supports. In some cases features may not be able to support everything, in which case this should be checked for and return errors appropriately. This applies to: windows OS versions (AutoIt has support for all OS' from windows 2000), unicode and ansi strings, 64 and 32 bit machines.
* Not use any magic numbers. Ever. None. At all. No excuses.

== UDF Outline ==
The library itself has a header that details important information such as the minimum OS and AutoIt versions, and what system dlls are required. There is also a number of other sections that are required that list what is present in the UDF.

=== Includes ===
Since a UDF is designed to define functions, it should only be included once. As a result, the <code>#include-once</code> directive should be used. This is typically the first line of the UDF, followed by the includes used by the UDF. Include statements should use the double quoted form, as the library is expected to work in the same directory as libraries it depends on. Non standard libraries can be used if necessary, but this should be documented and linked to so users can download it as well. It goes without saying that a UDF based on non-standard UDFs cannot itself become a standard.

=== Index ===
The index follows the following template (taken from <code>WinAPI.au3</code>):

<syntaxhighlight lang="autoit">; #INDEX# =======================================================================================================================
; Title .........: Windows API
; AutoIt Version : 3.2
; Description ...: Windows API calls that have been translated to AutoIt functions.
; Author(s) .....: Paul Campbell (PaulIA), gafrost, Siao, Zedna, arcker, Prog@ndy, PsaltyDS, Raik, jpm
; Dll ...........: kernel32.dll, user32.dll, gdi32.dll, comdlg32.dll, shell32.dll, ole32.dll, winspool.drv
; ===============================================================================================================================</syntaxhighlight>

The only required element in the index header is <code>Title</code>. All others are ignored by the processor, but should be included for reference

The <code>Dll</code> field can remain empty in many cases where no dlls are called directly. This header must be defined.

=== Other Sections ===
Other sections, in order of appearance, are as follows.

==== Variables ====
All global variables needed to be declared in the UDF are defined in this section. They should follow the variable rules for globals. Individual variables do not need to be documented, as it is assumed they are for internal use only. Any globals designed to be accessible for the user should instead be wrapped by a function (or multiple functions if globals must be retrieved and set). The template for this section is:

<syntaxhighlight lang="autoit">; #VARIABLES# ===================================================================================================================
Global $__gvMyGlobal = 0
; ===============================================================================================================================</syntaxhighlight>

If no globals are needed then this section may be ommitted. Please consider the use of global variables carefully, and read through the section on global variables.

==== Constants ====
Any global constant values are defined in this section. This should be constants only designated for use within the library itself. Constants that may be needed by the user should be defined in a separate file, named <code>UDFConstants.au3</code> where <code>UDF</code> is the name of the parent file. For example <code>File.au3</code> uses constants defined in <code>FileConstants.au3</code>. The exception to that rule is control UDFs which miss out the prepended 'GUI' when naming constant files, so <code>GUIButton.au3</code> uses constants from <code>ButtonConstants.au3</code>. The template for this section is:

<syntaxhighlight lang="autoit">; #CONSTANTS# ===================================================================================================================
Global Const $__MYUDFCONSTANT_FOOBAR = 42
; ===============================================================================================================================</syntaxhighlight>

If no constants are needed in this section, either because none are used or because they are stored in a separate file, then it may be ommitted. Please read the section on global constants for specific info on naming and definition of constants.

==== Listing ====
This defines all functions and structures currently used functions in the library. It MUST be the second defined header item after [[#Index]]. It is a simple list with each function on a line where the functions and structures appear in the same order as they do in the code, which is alphabetical order and structures first. A simple way to generate this list is to create a small script that searches for function definitions and outputs them in the correct format, an example of which is [http://www.autoitscript.com/forum/topic/120820-function-name-lister/ here]. In addition there is a second section that lists functions and structures for internal use only, this does not need to appear if none are defined.

The template for these sections are:

<syntaxhighlight lang="autoit">; #CURRENT# =====================================================================================================================
;$tagSTRUCT
;_MyUDF_Function
; ===============================================================================================================================

; #INTERNAL_USE_ONLY# ===========================================================================================================
;$tagINTERNALSTRUCT
;__MyUDF_InternalFunction
; ===============================================================================================================================</syntaxhighlight>

This section still needs to be defined for files that only define constants. It should also be noted that there MUST NOT be a space between the <code>;</code> and the function/structure name.

==== Undocumented Listing ====
There is a final kind of listing that lists functions for which no documentation exists, or they have been deprecated and are only included for backwards compatibility. These are listed in a section with the header <code>NO_DOC_FUNCTION</code>. This is very rarely used, and is reserved only for functions that can be utilised by the user, or that would have been in the past, as opposed to those for internal use only.

Template:

<syntaxhighlight lang="autoit">; #NO_DOC_FUNCTION# =============================================================================================================
;_MyUDF_Function
; ===============================================================================================================================</syntaxhighlight>

==== Renamed Functions ====
Although it should not be the case in new UDFs, many of the older ones (particularly to do with controls) have had script breaking name changes to functions. These are documented in the UDF to ensure updating old scripts is as easy as possible. The basic format for this is:

<syntaxhighlight lang="autoit">; #NO_DOC_FUNCTION# =============================================================================================================
;_MyUDF_OldFunction ; --> _MyUDF_NewFunction
; ===============================================================================================================================</syntaxhighlight>

The space padding is optional. This section is ignored as far as the docs are concerned, and is usually omitted.

== Functions ==
=== Naming ===
Function names must start with an underscore, and the first word is the library name. There is then usually another underscore before the rest of the function name. The library name should be consistent across all the functions in the library, and can be shortened if a logical abbreviation is available (e.g. <code>Window</code> ==> <code>Win</code>). Each word should be capitalized, but no underscores are placed in the rest of the name, for example <code>_WinAPI_GetWindowLong</code>.

For control libraries, the first part of the function name is changed slightly. For example the UDF for listviews would use <code>_GUICtrlListview_*</code>. When a function wraps a dll call, then the second part should closely resemble the function name as it appears in other languages. This also applies to functions acting as a wrapper to <code>SendMessage</code>.

Functions are defined in alphabetical order by name, which is the same as using <code>Tidy</code> with the <code>/sf</code> flag set.

=== Parameters ===
Parameters should follow the variable naming scheme ([[#Naming_2|here]]). All parameters must be checked to ensure they are valid, and return unique and documented error codes if they are not. For functions involving a specific type of control, this includes checking the class name using <code>_WinAPI_IsClassName</code>.

Parameters that are optional or byref should be documented as such, and the effect these have explicitly stated. For example a byref parameter should detail exactly what the expected output is as well as the input.

=== Headers ===
All functions have a documentation header that describes the function. This uses the following template:

<syntaxhighlight lang="autoit">; #FUNCTION# ====================================================================================================================
; Name...........: _WinAPI_GetMousePos
; Description ...: Returns the current mouse position
; Syntax.........: _WinAPI_GetMousePos([$fToClient = False[, $hWnd = 0]])
; Parameters ....: $fToClient - If True, the coordinates will be converted to client coordinates
; $hWnd - Window handle used to convert coordinates if $fToClient is True
; Return values .: Success - $tagPOINT structure with current mouse position
; Failure - Zero
; Author ........: Paul Campbell (PaulIA)
; Modified.......:
; Remarks .......: This function takes into account the current MouseCoordMode setting when obtaining the mouse position. It
; will also convert screen to client coordinates based on the parameters passed.
; Related .......: $tagPOINT, _WinAPI_GetMousePosX, _WinAPI_GetMousePosY
; Link ..........:
; Example .......: Yes
; ===============================================================================================================================
Func _WinAPI_GetMousePos($fToClient = False, $hWnd = 0)</syntaxhighlight>

The header is 129 characters wide, and any text within it should be wrapped to that length. For example the <code>Remarks</code> in the above header has been extended to cover two lines. The exception to that rule is the <code>Syntax</code> line, which should not be wrapped. Some of the parameters in the header are optional, in which case they should remain, but be left empty (for example the <code>Link</code> and <code>Modified</code> lines in the above header). In others, they are needed, but can be empty or not used such as <code>Parameters</code> or <code>Return Values</code>. In this case the value should be 'None', as they will still be present in the documentation.

There are some flags that can be used within function headers:

* '''+''' in column 20 is the continuation flag for the previous line (used in Parameters, Return Values)
* '''|''' in column 20 is a new line in the right side of the table when the help file is generated (used in Parameters, Return Values)
* '''-''' in column 20 will create new row in the table, used for things like Defaults for a style (used in Parameters, Return Values)
* '''+''' in column 2 of Remarks is a blank line
Name
:Specifies the name of the function. This will be identical to how it appeas in the Func statement in the code itself.
Description
:Gives a short summary of what the function does. This should only be a single line, as it is only designed to give a short impression of what is happening. For the standard set of includes distributed with AutoIt3, this value is also used in the SciTE calltips.
Syntax
:Describes the syntax of the function call. This differs slightly from what appears in the code itself for optional parameters, which are enclosed in square brackets ("[ ]"). Since subsequent parameters must also be optional, and cannot be defined unless all the previous ones have been given, these brackets are nested in the form: Function([param1[, param2[,param3]]]). Note that the opening bracket appears before the comma seperator.
Parameters
:This is a list of the arguments accepted by the function. Each is listed, followed by a dash ("-") and a description of what it is. The dash can be padded for neatness, although the amount of padding depends on how long the parameter names are. If the parameter is optional then the meaning of the default value should be given, similarly if it's used to pass data back to the program in the form of byref then the changes made should also be detailed. For more information on parameters see Parameters.
Return values
:Details what is returned by the function. This often comes in the form of Success and Failure values, but this is not always the case. Any setting of the @error of @extended flags should be detailed, along with their meanings, in some cases it is enough to say that @error is set to non-zero in the event of an error, in most cases though a list of values for @error should be given.
Author
:This is the original writer of the function. It should contain the username, so that any queries about the code can be made through the forum, but you can give as much or little information as you feel appropriate.
Modified
:This is a list of modifications made. At it's most basic this is just a list of users who have made changes, but ideally it includes some information about what they did, in which cases it follows the same form as other multi-value lines, with the username and description of modifications seperated by a dash.
Remarks
:This is anything the user should know about a function in order to use it. For example exceptional cases and recommended ways to handle the function should all be detailed here, as well as additional info about possible reasons for failure and how to deal with them.
Related
:A comma seperated list of functions or structures related to the function.
Link
:A link to additional information about the function. For many system function wrappers, this will be <code>@@MsdnLink@@ FunctionName</code>, which represents that the user should search MSDN for the function.
Example
:A simple yes or no value specifying whether the function has an example. If this is no then your UDF is not ready to be released. The [[#Examples]] section has more information on the format and location of examples.

The easiest way to generate the header is to copy and paste the following blank template in:

<syntaxhighlight lang="autoit">; #FUNCTION# ====================================================================================================================
; Name...........:
; Description ...:
; Syntax.........:
; Parameters ....:
; Return values .:
; Author ........:
; Modified.......:
; Remarks .......:
; Related .......:
; Link ..........:
; Example .......:
; ===============================================================================================================================</syntaxhighlight>

There are also a number of plugins for SciTE that will generate a header and maybe fill in certain known values for you such as Name, Syntax and Parameters. The most complete one that conforms to these standards is [http://code.google.com/p/m-a-t/wiki/UDFHeaderGenerator here], but there are two others [http://www.autoitscript.com/forum/topic/28270-lua-script-for-udf-header/ here] and [http://www.autoitscript.com/forum/topic/28270-lua-script-for-udf-header/page__view__findpost__p__200823 here].

=== Internal use only ===
Functions can also be marked for use only within the library and not to be documented for use by the user. These are named according to the same rules as normal functions but begin with a double underscore ("__"). The header is exactly the same except with the first line replaced, to make the blank template:

<syntaxhighlight lang="autoit">; #INTERNAL_USE_ONLY# ===========================================================================================================
; Name...........:
; Description ...:
; Syntax.........:
; Parameters ....:
; Return values .:
; Author ........:
; Modified.......:
; Remarks .......:
; Related .......:
; Link ..........:
; Example .......:
; ===============================================================================================================================</syntaxhighlight>

== Structures ==
Structures are defined as global constants, and follow the naming pattern <code>$tagSTRUCTNAME</code>. The struct name should be as it appears on MSDN if it's used in the windows API, or follow a similar pattern if not. It should go without saying that they must work for both 32 and 64 bit machines, including resolving any alignment issues. Elements should also be named as they appear on MSDN if they are taken from there, which includes the hungarian notation prefix. Although many standard UDFs do not follow that rule, importantly <code>StructureConstants.au3</code>, the rule still stands.

=== Headers ===
Structures need a header similar to functions, but with some minor differences. The same rules apply in terms of wrapping and line length however. The header follow this standard template:

<syntaxhighlight lang="autoit">; #STRUCTURE# ===================================================================================================================
; Name...........: $tagPOINT
; Description ...: Defines the x and y coordinates of a point
; Fields ........: X - Specifies the x-coordinate of the point
; Y - Specifies the y-coordinate of the point
; Author ........: Paul Campbell (PaulIA)
; Remarks .......:
; Related .......:
; ===============================================================================================================================
Global Const $tagPOINT = "long X;long Y"</syntaxhighlight>

It is essentially a shortened header, with the only thing new is the Fields line, which effectively replaces the Parameters field in terms of usage. All the same rules apply as listed [[#Function Header Fields|here]].

The blank template is:

<syntaxhighlight lang="autoit">; #STRUCTURE# ===================================================================================================================
; Name...........:
; Description ...:
; Fields ........:
; Author ........:
; Remarks .......:
; Related .......:
; ===============================================================================================================================</syntaxhighlight>

Structures may also be marked for internal use only. In this case the header ramains the same, but the sections first line changes. The blank template is:

<syntaxhighlight lang="autoit">; #INTERNAL_USE_ONLY# ===========================================================================================================
; Name...........:
; Description ...:
; Fields ........:
; Author ........:
; Remarks .......:
; Related .......:
; ===============================================================================================================================</syntaxhighlight>

== Variables ==
For code readability, there are special rules dealing with variables, particularly naming. All variables should be declared at the beginning of their scope, which usually means at the start of the function in which they are used, but could mean the top of the UDF itself in the [[#Variables|Variables section]].

=== Naming ===
A variable's first letter signifies the expected type of the variable. This should be as follows:

* <code>$a<letter></code> - Array (the following letter describes the data type taken from the rest of the data types below, if it varies then <code>v</code> should be used. A counter as the first element is ignored, so the array returned by StringSplit (with default options) would actually be marked as $as despite the integer in the zeroeth element).
* <code>$m</code> - Map collection.
* <code>$d</code> - Binary data.
* <code>$h</code> - Handle, usually to a file or window. NB: AutoIt handled controls return IDs, and so use $id instead.
* <code>$id</code> - An AutoIt control Id.
* <code>$i</code> - Integer.
* <code>$b</code> - Boolean.
* <code>$f</code> - Floating point number.
* <code>$n</code> - general number with no preference for floating point or integer.
* <code>$s</code> - String.
* <code>$v</code> - Variant (unknown/variable type of data) .
* <code>$p</code> - Pointer. It is assumed that it points to a struct so no further letters are needed. The type of struct being pointed to should be inferrable from the variable name e.g. <code>$pWindowRect</code> can be assumed to be a pointer to a <code>$tagRECT</code> structure.
* <code>$t</code> - Structure returned from DllStructCreate.
* <code>$tag</code> - Struct definition string.Structure definitions should conform to the structure guidelines.

=== Globals ===
The use of globals in a UDF is generally frowned upon, and byref parameters and static variables should be used where possible instead. However, in cases where this is not possible and a global must be used they should be defined using the following naming pattern: <code>$__g<VARNAME>_<UDF></code> where <code><VARNAME></code> is the name as it would usually appear according to the variable naming rules above and <code><UDF></code> is the name of the library in which it appears. This ensures there will never be a conflict with user variables of other UDF globals. They should be declared at the top of the UDF in the Variables section.

Globals are always private. If they need to be accessed by the user then functions need to be written wrapping that operation and values should be checked. Notable exceptions are debug variables, which are designed for developer purposes and may be used by some users in extreme cases. These are named <code>$Debug_<UDF></code> although the <code><UDF></code> part is often shortened so <code>GUIEdit.au3</code> uses <code>$Debug_Ed</code>. It is not required that a UDF has debugging symbols, but they are allowed to remain in releases.

=== Constants ===
There are two types of constants, internal and public. Public constants are designed to be utilised by the user, and are referenced in functions that use them. They include styles and flags. Internal constants are designed for use only within the library, so that values used fairly often can be held in one place to allow for easy updating. Both kinds of constant are always typed in all upper case. Constants taken from the windows API should appear exactly as they are defined there, but internal constants follow the naming pattern: <code>$__<UDF>CONSTANT_<NAME></code>.

=== The <code>Dim</code> statement ===
Should not be used.

== Examples ==
All functions and structures that are made public to the user need to have a good quality example. This means that it should:

* Be simple. Ideally the only functions used are basic functions like ConsoleWrite and MsgBox and the function that the example is written for. Writing a single example that covers a wide range of functions is not nearly as easy to use as writing an example per function that clearly demonstrates its use.
* Be readable. Everything should be explained step by step in comments.
* Be correct. In addition to passing the same Au3Check flags as the UDF itself (<code>-q -d -w 1 -w 2 -w 3 -w- 4 -w 5 -w 6 -w- 7</code>) it should always be written with best practice being the main consideration. This takes preference over the first point, just because code is shorter and looks easier doesn't mean it's right.
* Examples should represent all the functionality. If there is more than one way of using a function then include more than one example of how to use it.
* Not make any permanent changes to the users computer. For example, if demonstrating a File function, be sure to delete the file after it has been used. The same applies for any function that makes a change to the environment: the changes MUST be undone.

Always remember, the readability of code in an example is MORE important than the readability of code inside the UDF itself.

Examples are stored in script files called <code><FUNCTION>.au3</code>. The files should be kept in a folder called <code>Examples</code>. To remain correct all examples should be wrapped in functions, such that the only code executed in the global scope is calling the function. This is usually named <code>Example</code>.

<syntaxhighlight lang="autoit">#include <Constants.au3>
#include <GUIConstantsEx.au3>

Opt("MustDeclareVars", 1)

Example()

Func Example()
Local $idButton_1, $idButton_2, $iMsg, $hGUI

$hGUI = GUICreate("My GUI Button") ; Will create a dialog box that when displayed is centered

$idButton_1 = GUICtrlCreateButton("Run Notepad", 4, 4, 80, 30)
$idButton_2 = GUICtrlCreateButton("Button Test", 4, 38, 80, 30)

GUISetState() ; will display a dialog box with 2 button

; Run the GUI until the dialog is closed
While 1
$iMsg = GUIGetMsg()
Select
Case $iMsg = $GUI_EVENT_CLOSE
ExitLoop
Case $iMsg = $idButton_1
Run("Notepad.exe") ; Will Run/Open Notepad
Case $iMsg = $idButton_2
MsgBox($MB_SYSTEMMODAL, "Testing", "Button 2 was pressed") ; Will demonstrate Button 2 being pressed
EndSelect
WEnd
GUIDelete($hGUI)
EndFunc ;==>Example</syntaxhighlight>

=== Multiple Examples ===
The helpfile now supports multiple examples per function. In order to maintain backwards compatibility with any other tools that use examples, the first file is still named <code><FUNCTION>.au3</code>, but any additional examples are named <code><FUNCTION>[n].au3</code> where n is an integer counter starting at 2.

== Template UDF ==
Here is an example of a UDF called <code>MyUDF.au3</code>:

<syntaxhighlight lang="autoit">#include-once

#include "MyUDFConstants.au3"
#include "AnInclude.au3"

; #INDEX# =======================================================================================================================
; Title .........: MyUDF
; AutoIt Version : 3.3.6.1
; Language ......: English
; Description ...: An example UDF that does very little.
; ===============================================================================================================================

; #CURRENT# =====================================================================================================================
;$tagMYSTRUCT
;_MyUDF_Function
; ===============================================================================================================================

; #STRUCTURE# ===================================================================================================================
; Name...........: $tagMYSTRUCT
; Description ...: An example of a structure.
; Fields ........: hFoo - A handle to foo that does something.
; iBar - An integer that does something.
; Author ........: Matt Diesel (Mat)
; Remarks .......:
; Related .......: _MyUDF_Function
; ===============================================================================================================================
Global Const $tagMYSTRUCT = "ptr hFoo; int iBar"

; #FUNCTION# ====================================================================================================================
; Name...........: _MyUDF_Function
; Description ...: A function that does something.
; Syntax.........: _MyUDF_Function(ByRef $avAnArray, $iAnInt[, $hAHandle = 0[, $nSomeNumber = 42]])
; Parameters ....: $avAnArray - [byref] An array of anything. The value of anything is changed and passed out using this
; parameter. The array should only have one dimension
; $iAnInt - An integer that does very little.
; $hAHandle - [optional] A handle. Default is zero.
; $nSomeNumber - [optional] A number of some kind. Default is 42.
; Return values .: Success - A MYSTRUCT structure.
; Failure - Returns zero and sets the @error flag:
; |1 - The $avAnArray is invalid.
; Author ........: Matt Diesel (Mat)
; Modified.......:
; Remarks .......:
; Related .......: $tagMYSTRUCT
; Link ..........:
; Example .......: No
; ===============================================================================================================================
Func _MyUDF_Function(ByRef $avAnArray, $iAnInt, $hAHandle = 0, $nSomeNumber = 42)
; 1 - Error Checking for parameters.
If Not IsArray($avAnArray) Or UBound($avAnArray, 0) <> 1 Then Return SetError(1, 0, 0) ; The $avAnArray is invalid.

; 2 - Declaration of locals.
Local $tMS = DllStructCreate($tagMYSTRUCT)

; 3 - Function code
DllStructSetData($tMS, "hFoo", $hAHandle)
DllStructSetData($tMS, "iBar", $iAnInt * $nSomeNumber)

Return $tMS
EndFunc ;==>_MyUDF_Function</syntaxhighlight>

Best coding practices

2014-07-29T12:13:41Z

Jpm: /* Names of Variables */

Outlined in this section is a detailed explanation of what is to be considered the best coding practices within AutoIt.

A few notes:
* You must use the latest version of AutoIt (v3.3.10.0 or above) to run the examples below.

__TOC__

== Names of Variables ==
The [http://en.wikipedia.org/wiki/Hungarian_notation Hungarian notation] is adopted however it's simplified and regroup all the types of numbers in one type.

Variables are initialized with the "default" value (or the most efficient value) of their type. See below in the table for specific value.

{| class="wikitable"
|-
! prefix !! covering type !! initialization
|-
| i || Integer || $i = 0
|-
| f || Floating point || $f = 0.0
|-
| n || General number (no preference) || $n = 0
|-
| a || Arrays || Dim $a[1]and $a[0] = "Value"
|-
| m || Maps || Dim $m[] and $m["key"] = "Value"
|-
| s || Strings (chars included) || $s = "" or $s = Null
|-
| b || Booleans || $b = False or $b = True
|-
| d || Binaries || $d = Binary("")
|-
| id || An AutoIt controlid || $id = 0
|-
| h || Handles (and GUI handles) || $h = 0
|-
| fu || Functions || $fu = Null
|-
| p || Pointers || $p = 0
|-
| tag || Structures definition || $tag = 0
|-
| t || Structures || $t = 0
|-
| o || Objects || $o = 0 or $o = Null
|-
| v || Variant || $v = 0 or $v = "" (or $v = Null)
|-
| e || Enumerations || N/A
|-
| k || Keywords || $k = Default
|}

The variables are named following this schema:
{| class="wikitable"
|-
! type (lower case) !! [optional] subtype (lower case) !! var name (first letter in upper case)
|-
| i || f || MyFlag
|}

Example:
<syntaxhighlight lang="autoit">
; Assign a Local variable the number 5.
Local $iSomeVar = 5

; Assign a Local variable the number 1.
Local $ifMyFlag = 1

; Assign a Local variable an array of numbers.
Local $aiArray = 0

; Re-declare the array to size and fill it.
Local $aiArray[3] = [0, 0.25, 3 / 4]
</syntaxhighlight>

Always initialize a variable on it's declaration, and declare all the same type of variable on the same line.

Example:
<syntaxhighlight lang="autoit">
;Bad
Local $iSomeVar1, $aiArray = 0
Local $iSomeVar2 = 5

;Good
Local $iSomeVar1 = 0, $iSomeVar2 = 5
Local $aiArray = 0
</syntaxhighlight>
You can still categorize your variables and declare for example the $iSomeVar2 on another line.

Example2:
<syntaxhighlight lang="autoit">
#include <MsgBoxConstants.au3>

Local $vValue ; Bad, this is initially blank.
Local $vVal = 0 ; Good

MsgBox($MB_SYSTEMMODAL, '', '$vValue: ' & $vValue & @CRLF & '$vVal: ' & $vVal)

; In C++ $vValue would display the previous value that was residing in the memory address $vValue points to. AutoIt
; is a little less forgiving in that it initialises the variable as being blank and doesn't throw any error, unlike some moder C++ compilers.
</syntaxhighlight>

== Scopes of Variables ==
To make the transition, the variables are also named according to their scope.
{| class="wikitable"
|-
! Global UDF variable !! Global variable !! Local variable
|-
| $g__iSomeVar || $g_iSomeVar || $iSomeVar
|}
With this method, you will avoid non wanted re-assignments.

Example:
<syntaxhighlight lang="autoit">
#include <MsgBoxConstants.au3>

; Assign a Global variable the number 0.
Global $iSomeVar1 = 0
; Assign a Global variable the number 5.
Global $_iSomeVar2 = 5

SomeFunc()

Func SomeFunc()
; Assign Local variables respectively the numbers 3 and 4.
Local $iSomeVar1 = 3, $iSomeVar2 = 4

; Note: The user inadvertently re-assigned the global variable $iSomeVar1, because this one is not named as "global".

; Display the value of $iSomeVar1.
MsgBox($MB_SYSTEMMODAL, "", "Value of $iSomeVar1: " & $iSomeVar1)

; Display the value of $iSomeVar2.
MsgBox($MB_SYSTEMMODAL, "", "Value of $iSomeVar2: " & $iSomeVar2)

; Display the value of $_iSomeVar2.
MsgBox($MB_SYSTEMMODAL, "", "Value of $_iSomeVar2: " & $_iSomeVar2)
EndFunc
</syntaxhighlight>

* A variable declared globally (with the Global keyword) is visible anywhere in the script.
Always declare your global variables in the global scope, not in the functions. It will prevent another function to use it before its declaration and the declaration is implicit (see [[#jumpsec1|examples]]).

* A variable declared locally (with the Local keyword), has a visibility which depends of the scope where it's declared.
:Declaration in the global scope: the variable is nonetheless visible everywhere; declare it as Local if this one is only used in the same scope.
:Declaration in a function: the variable is visible by the function itself and nowhere else.

Structure of a code scope:
<syntaxhighlight lang="autoit">
; Global scope.

; Include the Constants file, it contains various constants; it's needed here for the $MB_SYSTEMMODAL flag of the MsgBox function).
#include <MsgBoxConstants.au3>

; This scope is either Global or Local, depending on where do you use the variables.

; Assign a Global variable the number 0 (which corresponds to an initialization of a variable number), its scope is Global because it's used at least in one function.
Global $_iVar1 = 0

; Assign a Local variable the string "foo", its scope is Local because it's use is restricted to this scope.
Local $_sVar2 = "foo"

; Display the content of $_sVar2
MsgBox($MB_SYSTEMMODAL, "", "Value of $sVar2: " & $_sVar2)

; Re-assign a Local variable the string returned by the function MyFunc.
$_sVar2 = MyFunc()

; Re-Display the content of $_sVar2
MsgBox($MB_SYSTEMMODAL, "", "Value of $sVar2: " & $_sVar2)

; Declare a function (its main utility is described later in Functions, we can see one here which is to create a Local scope).
Func MyFunc()
; Local scope.

; Display the content of $_iVar1.
MsgBox($MB_SYSTEMMODAL, "", "Value of $_iVar1: " & $_iVar1)

; Assign a Local variable the string "bar", its scope is Local because it's use is restricted to the function's scope.
Local $sVar3 = "bar"

; Display the content of $sVar3.
MsgBox($MB_SYSTEMMODAL, "", "Value of $sVar3: " & $sVar3)

; Return the $sVar3 content, it will be visible (if used) to the scope where the function is called.
Return $sVar3
EndFunc ;==>MyFunc
</syntaxhighlight>

Concerning the Dim keyword, its recommended usage is limited to empty an existing array (Example 1) or to redeclare a function parameter (Example 2).

Example 1:
<syntaxhighlight lang="autoit">
; Include the Array UDF, it's needed here for the _ArrayDisplay function.
#include <Array.au3>

; Assign a Local variable an array containing numbers with a size of 5.
; Note than an array is based 0 index, to access the first element the code is: $aiArray[0].
Local $aArray[5] = [1, 2, 3, 4, 5]

; Display the contents.
_ArrayDisplay($aArray)

; Empty the array (and keep its size).
Dim $aArray[5]

; Display the contents.
_ArrayDisplay($aArray)
</syntaxhighlight>
Remark: The variable type of the emptied array is a string, every variable non initialized is a string.

Example 2:
<syntaxhighlight lang="autoit">
#include <Array.au3>

; Call MyFunc with default parameters ($vParam1 = 0).
MyFunc()

; Assign a Local variable an array containing integers.
Local $aiArray[3] = [3, 4, 5]
; Call MyFunc with $aiArray as parameter ($vParam1 = $aiArray).
MyFunc($aiArray)

Func MyFunc($vParam1 = 0)
; If $vParam1 is NOT an array then redeclare it to an array.
If IsArray($vParam1) = 0 Then
Dim $vParam1[3] = [0, 1, 2]
EndIf

; Display the array.
_ArrayDisplay($vParam1)
EndFunc ;==>MyFunc
</syntaxhighlight>

And for the ReDim keyword, limit its use to resize an array you want to keep its content:
<syntaxhighlight lang="autoit">
; Include the Array UDF, it's needed here for the _ArrayDisplay function.
#include <Array.au3>

; Assign a Local variable an array containing numbers with a size of 5.
; Note than an array is based 0 index, to access the first element the code is: $aiArray[0].
Local $aArray[5] = [1, 2, 3, 4, 5]

; Display the contents.
_ArrayDisplay($aArray)

; Resize the array (and keep its content).
ReDim $aArray[3]

; Display the contents.
_ArrayDisplay($aArray)
</syntaxhighlight>

Why using Dim over Local/Global is not always a good option:
<syntaxhighlight lang="autoit">
#include <MsgBoxConstants.au3>

Dim $vVariableThatIsGlobal = "This is a variable that has ""Program Scope"" aka Global."

MsgBox($MB_SYSTEMMODAL, "", "An example of why Dim can cause more problems than solve them.")

Example()

Func Example()
MsgBox($MB_SYSTEMMODAL, "", $vVariableThatIsGlobal) ; That looks alright to me as it displays the following text: This is a variable that has "Program Scope" aka Global.

Local $vReturn = SomeFunc() ; Call some random function.

MsgBox($MB_SYSTEMMODAL, $vReturn, $vVariableThatIsGlobal) ; The Global variable ($vVariableThatIsGlobal) changed because I totally forgot I had a duplicate variable name in "SomeFunc".
EndFunc ;==>Example

Func SomeFunc()
; This should create a variable in Local scope if the variable name doesn"t already exist.
; For argument sake I totally forgot that I declared a variable already with the same name.
; Well I only want this to be changed in the function and not the variable at the top of the script.
; Should be OK right? Think again.
Dim $vVariableThatIsGlobal = ""

For $i = 1 To 10
$vVariableThatIsGlobal &= $i ; This will return 12345678910 totally wiping the previous contents of $vVariableThatIsGlobal.
Next
Return $vVariableThatIsGlobal
EndFunc ;==>SomeFunc
</syntaxhighlight>

<span id="jumpsec1">Declaring Global variables in a Function is never a good idea:</span>
<syntaxhighlight lang="autoit">
#include <MsgBoxConstants.au3>

; Calling Example() first will initialise the Global variable $vVariableThatIsGlobal and therefore calling SomeFunc() won't return an error.
; Now look at Example 2.
Example()

Func Example()
; Declaring a variable in a function can cause serious problems, hence why all Global variables should be declared at the top of a script.
Global $vVariableThatIsGlobal = 'This is a variable that has ''File Scope'' aka Global.'
SomeFunc()
EndFunc ;==>Example

Func SomeFunc()
MsgBox($MB_SYSTEMMODAL, '', $vVariableThatIsGlobal) ; As the variable was initialised this will not return an error.
EndFunc ;==>SomeFunc
</syntaxhighlight>

Example 2:
<syntaxhighlight lang="autoit">
#include <MsgBoxConstants.au3>

; Calling SomeFunc() first will bypass the Global variable $vVariableThatIsGlobal being initialised and therefore AutoIt has no idea of what data the variable
; $vVariableThatIsGlobal contains.
SomeFunc()

Func Example()
; Declaring a variable in a function can cause serious problems, hence why all Global variables should be declared at the top of a script.
Global $vVariableThatIsGlobal = 'This is a variable that has ''File Scope'' aka Global.'
SomeFunc()
EndFunc ;==>Example

Func SomeFunc()
MsgBox($MB_SYSTEMMODAL, '', $vVariableThatIsGlobal) ; As the variable wasn't initialised this will return an error of "variable used without being declared."
EndFunc ;==>SomeFunc
</syntaxhighlight>

Declaring variables in loops (For, While, Do etc..) can have an affect on efficiency:
<syntaxhighlight lang="autoit">
#include <MsgBoxConstants.au3>

; Declaring variables inside loops should be avoided as the variable is re-declared on each repetition.
For $i = 1 To 10 ; $i is in 'loop scope.'
Local $iInt = $i
Next
MsgBox($MB_SYSTEMMODAL, '', $iInt) ; This will display 10.
</syntaxhighlight>

<syntaxhighlight lang="autoit">
#include <MsgBoxConstants.au3>

; Declaring variables outside of loops is more efficent in the long run.
Local $iInt = 0
For $i = 1 To 10 ; $i is in 'loop scope.'
$iInt = $i
Next
MsgBox($MB_SYSTEMMODAL, '', $iInt) ; This will display 10.
</syntaxhighlight>

There is no requirement to declare the iteration count variable in a loop:
<syntaxhighlight lang="autoit">
; Correct
Local Const $iCount = 99
Local $aArray[$iCount]
For $i = 0 To UBound($iCount) - 1 ; $i is only used in the loop, so there is no requirement to declare it.
$aArray[$i] = $i
Next

; Incorrect
Local Const $iCount = 99
Local $aArray[$iCount]
Local $i ; This is only used to store the iteration count value in the loop and therefore doesn't need to be declared. This is known as loop scope.
For $i = 0 To UBound($iCount) - 1
$aArray[$i] = $i
Next
</syntaxhighlight>
As you can see, there is the Const keyword in the example, we are going to talk about it.

== Const, Static, Enum ==

=== Const ===
We won't talk about the advantages of a constant variable, they are neglibible (for your information, an autoit constant variable is marked as read-only and remains a variable as read-only when compiled).

The Const keyword may be used in a first by some of you to avoid re-assignments.
The best way to use them is not this last case, the constants should be used for real static variables, meaning that their value won't change regardless to the instance of the program.

Example:
<syntaxhighlight lang="autoit">
;Bad
Local Const $hGUI = GUICreate("MyGUI")
; The handle of the window is unique, it's generated by Windows and changes.

;Good
Local Const $iMyAge = 19
</syntaxhighlight>

=== Static ===
Static variables are the solution to the global variables used in only one function.
e.g: Retain variable data once returned from a Function and only use that variable in that particular Function.
<syntaxhighlight lang="autoit">
Example()

Func Example()
SomeFunc() ; This will display a message box of 1, 1.
SomeFunc() ; This will display a message box of 1, 2.
SomeFunc() ; This will display a message box of 1, 3.
EndFunc ;==>Example

Func SomeFunc()
; This initialises a Static variable in Local scope. When a variable is declared just in Local scope (within a Function,)
; it's destroyed when the Function ends/returns. This isn't the case for a Static variable. The variable can't be
; accessed from anywhere else in the script apart from the Function it was declared in.
Local Static $vVariableThatIsStatic = 0
Local $vVariableThatIsLocal = 0
$vVariableThatIsLocal += 1 ; This will always be 1 as it was destroyed once returned from SomeFunc.
$vVariableThatIsStatic += 1 ; This will increase by 1.
MsgBox(4096, $vVariableThatIsLocal, $vVariableThatIsStatic)
EndFunc ;==>SomeFunc
</syntaxhighlight>

=== Enum ===
This statement is often practical in certain situations:
<syntaxhighlight lang="autoit">
#include <MsgBoxConstants.au3>

Example()

Func Example()
; Create variables in Local scope and enumerate through the variables. Default is to start from 0.
Local Enum $eCat, $eDog, $eMouse, $eHamster ; $eHamster is equal to the value 3, not 4.

; Create an array in Local scope with 4 elements.
Local $aAnimalNames[4]

; Assign each array element with the name of the respective animal. For example the name of the cat is Jasper.
$aAnimalNames[$eCat] = 'Jasper' ; $eCat is equal to 0, similar to using $aAnimalNames[0]
$aAnimalNames[$eDog] = 'Beethoven' ; $eDog is equal to 1, similar to using $aAnimalNames[1]
$aAnimalNames[$eMouse] = 'Pinky' ; $eMouse is equal to 2, similar to using $aAnimalNames[2]
$aAnimalNames[$eHamster] = 'Fidget' ; $eHamster is equal to 3, similar to using $aAnimalNames[3]

; Display the values of the array.
MsgBox($MB_SYSTEMMODAL, '', '$aAnimalNames[$eCat] = ' & $aAnimalNames[$eCat] & @CRLF & _
'$aAnimalNames[$eDog] = ' & $aAnimalNames[$eDog] & @CRLF & _
'$aAnimalNames[$eMouse] = ' & $aAnimalNames[$eMouse] & @CRLF & _
'$aAnimalNames[$eHamster] = ' & $aAnimalNames[$eHamster] & @CRLF)

; Sometimes using this approach for accessing an element is more practical than using a numerical value, due to the fact changing the index value of
; the enum constant has no affect on it's position in the array. Therefore changing the location of $eCat in the array is as simple as changing the order
; it appears in the initial declaration e.g.

; Local Enum $eDog, $eMouse, $eCat, $eHamster

; Now $eCat is the 2nd element in the array. If you were using numerical values, you would have to manually change all references of $aAnimalNames[0] to
; $aAnimalNames[2], as well as for the other elements which have now shifted.
EndFunc ;==>Example
</syntaxhighlight>

== Au3Check directive ==
As you may know (and we hope), the Au3Check tool checks your code for syntax errors, variables used without being declared etc. which is a good thing to fix your script.

With the official custom directive used to check the helpfile examples/includes, you can apply the good coding practices listed above:
<syntaxhighlight lang="autoit">
#AutoIt3Wrapper_Au3Check_Parameters=-q -d -w 1 -w 2 -w 3 -w- 4 -w 5 -w 6 -w- 7
</syntaxhighlight>

== Magic Numbers ==
Magic numbers are arbitrary numbers interspersed throughout a program's source code which do not have an associated identifier. The downside to this is not being able to derive a meaning from the number.

For example:
<syntaxhighlight lang="autoit">
MsgBox(262144, "Magic Numbers", "It's Adventure Time!")
</syntaxhighlight>
In this example, the magic number is 262144 with the identifier being $MB_TOPMOST according to the helpfile.

Example 2:
<syntaxhighlight lang="autoit">
; Imagine you're a new user to AutoIt and you come across this code, where would you find -3, -4 or -5 in the help file?
; Since AutoIt is relatively a new concept to you, your first thought isn't to search through all the include files, I mean
; why would you, the help file is there for a reason.
Example()

Func Example()
Local $hGUI = GUICreate('')
GUICtrlCreateLabel('Why magic numbers are counter productive.', 5, 5)
GUICtrlSetState(Default, 128) ; Does this hide, show or disable it?
GUICtrlSetState(Default, 64) ; Does this hide, show or disable it?
GUISetState(@SW_SHOW, $hGUI)

While 1
Switch GUIGetMsg()
Case -3 ; Doesn't really tell much about what it does.
ExitLoop

Case -4, -5 ; Again, no idea what these are. MouseMove? MouseClick? Restore?
MsgBox(4096, '', 'Do something when this action takes place.')

EndSwitch
WEnd

GUIDelete($hGUI)
EndFunc ;==>Example
</syntaxhighlight>

Did you understand the numbers were these:
<syntaxhighlight lang="autoit">
#include <GUIConstantsEx.au3>

Example()

Func Example()
Local $hGUI = GUICreate('')
GUICtrlCreateLabel('Why magic numbers are counter productive.', 5, 5)
GUICtrlSetState(Default, $GUI_DISABLE) ; Better, this is documented in the help file.
GUICtrlSetState(Default, $GUI_ENABLE) ; Better, this is documented in the help file.
GUISetState(@SW_SHOW, $hGUI)

While 1
Switch GUIGetMsg()
Case $GUI_EVENT_CLOSE ; Better, this is documented in the help file. Ah, it's the close action.
ExitLoop

Case $GUI_EVENT_MINIMIZE, $GUI_EVENT_RESTORE ; Better, this is documented in the help file.
MsgBox($MB_SYSTEMMODAL, '', 'Do something when this action takes place.') ; Better, this is documented in the help file.

EndSwitch
WEnd

GUIDelete($hGUI)
EndFunc ;==>Example
</syntaxhighlight>

[http://en.wikipedia.org/wiki/Magic_number_(programming) Magic number (programming)]

== Include-once directive ==
This one is designed for standard includes and UDFs, it's highly recommended to use it.

Those includes may be included in more than one script of your project because they are needed for some includes or your script itself.
In that case, the code will be duplicated which is not a good thing especially if you have (and it's mainly the case) constants declared in those files, in so far as the constants cannot be redeclared/reassigned; same thing for functions.

Put the directive in top of your UDF (library) to avoid itself to be included more than once :
<syntaxhighlight lang="autoit">
#include-once
</syntaxhighlight>