As you begin to expand your use of AutoHotkey

Like philip did from last week’s post

It’s common that a need or desire to write code

That performs complex operations arise

Or the wish to use more

Advanced functionality of AutoHotkey comes up

Simply writing line after line

Will not always give you the best Ahk scripts in the end.

In a normal day:

I often write many types of scripts

And see a lot of code written by others.

 

To say that the code I see and write varies a little, in style and complexity would be an understatement.

While it is perfectly understandable

That not everyone feels or thinks the same way

 

Differences throughout a community like the one at Autohotkey.com

And maybe also the sheer number of new users to the autohotkey community overall

Put together with the lacking need for following any kind of strict whitespace guidelines

Perhaps a lack of prior knowledge (or ability) for writing code

Makes it hard to always follow the intent and flow of an Autohotkey script

 

The lack of any best practices to follow

Prompted me to write this post

In the hopes of helping you avoid (or remedy) this problem

 

I will name and try to explain

Some of what I feel is:

The most useful best practices

And share my own tips for writing reliable and reusable code.

 

This post will focus on Autohotkey scripting in general

So if you haven’t studied or done any coding before

Or is simply new to Autohotkey, then check out the Resources page and please keep reading!

 

KEEP STYLING CONSISTENT

First and foremost:

You need to indent your code consistently (i.e put spaces or tabs in front of code).

 

Much like reading a book

You learn to read (and write) code by knowing how the control (program flow) will branch based on conditions, loops, etc.

One book to help with that is the Practice of Programming

 

If you do not indent your code

It often becomes very difficult to understand what the code does

And recognize how to successfully make changes to it.

For example: By using indentation consistently

You can avoid having to count how many open or close curly braces there are when identifying which IF or LOOP block the current line of code happens to be in.

Trust me, it’s easier!

And, considering that Editors like notepad++ and sciTE4ahk has the ability to “Auto indent” as part of the normal use, you really have no excuses.

 

WHY YOU MAY WANT TO KNOW YOUR DATA TYPES

Some languages are non-negotiable

When it comes to assigning values to variables defined as a specific type

Otherwise known as “Type Safety.”

AutoHotkey, on the other hand, is not one of those languages.

AutoHotkey is actually extremely flexible

 

Which is good and bad.

The good side of this is:

That AutoHotkey will simply work with whatever data type you put in your variable

But the bad side of this is that:

For new users it promotes a lack of discipline when writing code.

 

Worse yet, is:

That you will never need to learn what data types you use

This becomes apparent when you someday wish to use commands like DllCall.

 

Another symptom of the problem

Relating to data types is

When a you try to do a comparison

Between two variables and it causes an unexpected result.

 

Some will say that you should always

Define your variables as known types (Strings can be defined as “” empty, Numbers as 0 zero, Boolean as true/false, etc).

In Autohotkey:

You’re in luck as you can get very far without ever needing to know what value type is in your variable

And you may never need to convert a single value

To a String or Number or any other type for that matter.

 

USE DESCRIPTIVE NAMES FOR VARIABLES AND FUNCTIONS

Avoid using variables with extremely short names

As this makes it difficult to understand

The purpose of the variable throughout the code.

Exceptions to this rule:

Include using single letter integers for iterating through loops (e.g. i).

 

You should also avoid using extremely long names

So try to find some middle ground

And give your variables a name with purpose.

The same thing applies to functions as

A greatly named function can tell you upfront what it’s doing.

 

USE OBJECTS

If you’re using an Autohotkey version downloaded in the last few years

You’re using an Prototype-based programming language, it is a style of object-oriented programming

So be sure to make full use of Objects.

For those new to Objects:

These are basically variables with more variables inside them.

 

Do you need to know all the ins and outs of how objects does their thing?

Not really!

You just need to know how to put things like variables in and get them out

Other then that just let it do it’s thing.

 

To me objects is a “thing” to use and there is no upfront need to understand all of what Oop is.

Do you want to learn Oop?

Start by using Oop stuff and then little by little tear other OOP scripts or functions apart to see how they do what they do.

See what’s in them and then try to make them do something a little different.

Make a dishwasher class, for example, getting it to set things it uses like dishes, soap and water.

 

On the other hand I often see code where

Multiple separate variables have been

Defined to store data that relates to the same entity (e.g. information regarding a single user such as First Name, Last Name and Email).

I feel it’s a great place to start

And to me it’s also far more useful to store these values in an Object

Which you can then easily

Pass between functions or even push into other objects!

But I do remember

That the single variable is easier to learn and, it has it’s place!

So if you don’t

Really feel a need to use objects that’s okay

But learning to use objects

Will help in the long run.

 

PREVENT CRASHES WITH ERROR TRAPPING

There are many reasons why your code can crash or produce undesired results.

A major cause is:

Failing to consider all of the possible scenarios

From a logical and technical point of view.

For example:

Think about where you need to process input from a user

If your AHk script expects a number but a user enters text

What will happen?

If you assumed the value would always be a number

And therefore did not allow for any exceptions

The code will likely fail.

To remedy this:

You can modify your code to allow exception cases to exist without crashing the script.

This is generally referred to as “error trapping”

Where the goal is to handle any exception cases

Without crashing your script.

 

A simple solution to the above scenario would be:

To detect the undesirable input value

And report an error message (using something like MsgBox) back to the user

Rather than letting the code continue running and potentially fail.

 

This simple principle of checking whether a value is within the nominal range

Or that the expected behavior has been used

Can make all the difference.

 

This can also be applied to:

Other parts like when values are returned by functions

Or when doing actions not handled by your own code.

 

COMMENT YOUR CODE

Last but not least

You should always comment your code.

Comments not only tell other people what your code does (or at least what it was intended to do)

It also lets you remind yourself what the code does.

 

Unless you have an exceptional memory

Click to tweet: Remembering exactly what each line of code does in a script or function you wrote 12 months earlier can be challenging.

 

As a wise developer once said:

Be kind to your future self and comment your code.

This is not to say that every line of code requires a comment, but I do suggest commenting the following:

• Functions ( Describe in a few lines the purpose of the function and what parameters or return values it needs or gives )
• IF blocks or loops ( Try and describe the purpose of each )
• Hotkey or Hotstrings ( Describe the routine with a few words )
• Groups of variables or Objects ( A single line describing what the group is for or holds )

 

LEARN MORE

These tips cover some of the basic principles of what I feel can be a base of Autohotkey scripting best practices.

Next week:

I’ll talk about AutoHotkey Hotkeys and how you Create, modify, enables, disables or make them context sensitive.

Do share and follow me on Twitter and Facebook.

Any Best Practices I missed?

Send me a message, or post your input as a comment below.

See you again soon.

Jackie