Skip to content
[WIP] AutoHotkey Best Practices
Branch: master
Clone or download
aviaryan Merge pull request #2 from KamalAwasthi/master
Added guidelines to use meaningful variable names
Latest commit 17573e1 Feb 20, 2016
Type Name Latest commit message Commit time
Failed to load latest commit information. add thanks Feb 20, 2016

AutoHotkey Best Practices

Good practices in AutoHotkey coding that will help avoid bugs and make your code more readable. This is currently a work in progress. Additions are welcome. See for contributing guidelines.

Table of Contents

  1. Indentation
  3. Hotkeys and Hotstrings
  4. Variables
  5. Strings
  6. Arrays and Objects
  7. Flow of Control
    1. If/Else
    2. Loops
    3. More
  8. Commands
  9. Functions
  10. Classes
  11. Directives
  12. Naming Convention


  • Indentation makes your code more readable and easy to debug and understand. You may use TABS or a consistent amount of spaces for indentation. (Source)
if (car == "old")
   msgbox, the car is really old
   if (wheels == "flat")
      msgbox, this car is not safe to drive.
      msgbox, Be careful! This old car will be dangerous to drive.
   msgbox, My`, what a shiny new vehicle you have there.


  • Single-line comments start with a semi-colon (;). You should precede the comment text with a space.
; Good
  • Multi-line comments are enclosed inside /* and */
/* comment
bad way to comment
good way to comment

Hotkeys and Hotstrings

  • For hotkeys, it is recommended to use multi-line syntax with return. Return will end the execution of the current executing subroutine. So in the following example, the execution after pressing Ctrl+J ends when Return is encountered. (Source)
    Send, My First Script


  • Prefer using := syntax wherever possible. It avoids confusion between variable names and literal strings.
var = some string ; bad
var := "some string" ; good
var = %onevar%%anothervar% ; bad
var := onevar . anothervar ; good
var = 2 ; bad
var := 2 ; good
  • Try to use the variable in the same case at different places.


  • Use concatenate (.) operator to break a long string into several lines rather than writing it in one long line.
; bad
var := "Lorem ipsum dolor sit amet, consectetur adipisicing elit. Dolore eos quas, sapiente sed voluptate repellendus asperiores modi excepturi ea ullam."
; good
var := "Lorem ipsum dolor sit amet, consectetur adipisicing elit. Officia laboriosam inventore"
    . "laudantium voluptas voluptate quasi, quae dolor unde repellendus quo."
  • For multi-line strings, prefer (...) syntax over manually adding `n at the end of every line.
; bad
s := "Lorem ipsum dolor sit amet, consectetur adipisicing elit. Totam, minima!`n"
    . "Lorem ipsum dolor sit amet, consectetur adipisicing elit. Eum, eaque.`n"
    . "Lorem ipsum dolor sit amet, consectetur adipisicing elit. Et, veniam."
; good
s := "
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Totam, minima!
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Eum, eaque.
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Et, veniam.

You can even use variables in between.

s := "
Line number 1
Line number 2
)" . myVar . "
Line number 5
Line number 6

Arrays and Objects

  • Use one space between values or key-value pairs in an Array declaration. It looks nicer.
Array := [2,4,6,8] ;bad
Array := [2, 4, 6, 8] ;good
AssociativeArray := {key1: Value1,key2:Value2, key3:Value3} ; bad
AssociativeArray := {key1: Value1, key2: Value2, key3: Value3} ; good

Flow of Control


  • In IF statements, use == instead of = for comparing. Again this avoids confusion and lots of bugs.
var := "AHK"

; bad
if var = AHK
    msgbox match

; good
if (var == "AHK")
    msgbox match


  • It is OK to omit the comma (,) if only one argument of a command is specified.
WinClose Notepad
  • Try to not use %var% variable syntax. It will be deprecated in AHK v2 and also is not consistent with many other programming languages around.
; bad
Run Notepad.exe %myFile%
; good
Run % "Notepad.exe " myFile

Naming Convention

  • Variable names consisting of many words should use camelCase or underscores for distinction.
farthestplanet := "Pluto" ; bad
farthest_planet := "Pluto" ; good
farthestPlanet := "Pluto" ; good
  • Variable names should be logical and should convey meaning about their purpose.
i := 40 ;bad
x_margin := 40 ;good
ff := "test.pdf" ;bad
fileName := "test.pdf" ;good
  • Class names should use PascalCase. This is consistent with many programming languages like C++, Python and Java.
; bad
class myclass {
; good
class MyClass {


You can’t perform that action at this time.