regarding modular scripting practice

[paik1002]

This is the coding style I am using currently:

1. main.ahk

Code: Select all

a::gosub jump_to_a

b::gosub jump_to_b

2. sub.ahk

Code: Select all

; functionality of hotkey a
jump_to_a:
	msgbox, this is a
return

; functionality of hotkey b
jump_to_b:
	msgbox, this is b
return

I am wondering what is the better scripting practice/style when it comes to modular coding.
The main reason I take this approach is due to visibility, a wider visual range (main.ahk) when a lot of hot keys are involved.
However, I am not quite certain if this approach is well... water-tight / future-proof style?


Should I use functions instead of gosubs? Any other suggestions? (before my script gets too large for a facelift.)

[waetherman]

It seems recently OOP gains more enemies than friends. Modular programming is especially good when you create libraries to be used in different scripts, especially by someone else. This way you can encapsulate some functionality in a module and document it's behavior. Reusing code that is part of a bigger script can potentially have same benefits, you just need to organize it properly - meaning for example, that independent chunks of code are separated, ideally in separate files.

You can take a look at my IntrusiveCALC ( https://bitbucket.org/Waetherman/intrusive-calc/ ) where I tried to follow OOP. There's a main script file, which is an application, and a module which can be easily reused in other apps. A good example for a "different app" is the unit test script.

What I don't like in AHK is that there's no default namespace scope inside a class that would let you use static constants of that class without using this classes name, as well as you have to use `this` keyword all the time. I also got surprised when I used a 'super global' variable by defining a variable in 'autostart' section of the script with `global` keyword - turned out the local variables I used inside my Calculator class where accessing super globals, so you should absolutely avoid using them if you care about encapsulation.

I kind of hoped more people will give feedback about IntrusiveCALC and correct any mistake I could have done, but having some background on OOP from other languages I can say that mimicking my style would be a good start for you.

Personally, I did kind of regret I went the OOP path with AHK - without good autocompletion and other functionality of good IDEs, OOP makes much less sense.

[lexikos]

I would use functions rather than subs, as a matter of preference. There isn't any particular reason that you can't use subs now and later use functions if they seem more suitable for the task. A facelift would only be needed if you were concerned about style, which isn't practical.

My hotkey script is full of quick-fix hotkeys, with minimal organisation. I find it adequate to just search (Ctrl+F) for a window title or hotkey if I think it exists. Otherwise it doesn't matter how the script is organised; I just pick a spot and add another quick-fix hotkey. Often there's nothing to gain by using a separate function/sub, and certainly no need for OOP.

Early on I split some of my hotkeys into files based on category, but this has actually made some of them harder to find quickly.

That's for my hotkey script, though, since the example had hotkeys; I suppose modularity is more important for function libraries or other programs written with AutoHotkey. To put it another way, my hotkey script is full of simple, unrelated hotkeys, so perhaps there's not as much potential for organisation as with a library or program, where everything is related.

I also got surprised when I used a 'super global' variable by defining a variable in 'autostart' section of the script with `global` keyword - turned out the local variables I used inside my Calculator class where accessing super globals, so you should absolutely avoid using them if you care about encapsulation.

If you declare a name as global and there are no declarations to the contrary, of course it's going to be treated as global. What did you expect?

The purpose of global varname outside a function is to make varname globally accessible, everywhere. If you don't want that, then certainly, avoid using it.

You could declare local varname inside the function, but then you run the risk of forgetting other declarations and ending up with global variables that were intended to be local. (This is because the presence of a local declaration makes the function assume all undeclared variables are global.)

[waetherman]

I also got surprised when I used a 'super global' variable by defining a variable in 'autostart' section of the script with `global` keyword - turned out the local variables I used inside my Calculator class where accessing super globals, so you should absolutely avoid using them if you care about encapsulation.

If you declare a name as global and there are no declarations to the contrary, of course it's going to be treated as global. What did you expect?

I wasn't whining, just sharing my experience as AHK noob.

I just got used to write a library, make it work and forget about it. AHK gives a dev a way to break the library from the outside. Maybe there should be a warning when using a superglobal, but other than that I can't criticize it, I just thought it's worth to mention it.

[lexikos]

I didn't think you were whining; I just don't understand your (former) point of view.

That sort of thing is a problem for every library, when the library or script enables warnings (specifically the local-same-as-global warning). Currently the only way around it is to declare all of your local variables, which also prevents super-global declarations from affecting the function. The proposed force-local mode could be another solution.