Skip to content

aviaryan/Ahk-Best-Practices

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

36 Commits
 
 
 
 

Repository files navigation

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 CONTRIBUTING.md for contributing guidelines.

Table of Contents

  1. Indentation
  2. Comments
  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

  • 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.
      Return
   }
   else
   {
      msgbox, Be careful! This old car will be dangerous to drive.
   }
}
else
{
   msgbox, My`, what a shiny new vehicle you have there.
}

Comments

  • Single-line comments start with a semi-colon (;). You should precede the comment text with a space.
;Bad
; Good
  • Multi-line comments are enclosed inside /* and */
/* comment
bad way to comment
*/
/*
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)
^j::
    Send, My First Script
Return

Variables

  • 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.

Strings

  • 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

If/Else

  • 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

Commands

  • 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 {
    
}

Thanks

About

[WIP] AutoHotkey Best Practices

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published