AutoIt best practices / coding style [closed]

Question

I maintain Autoit project used for automated testing of swing app. Those tests have now about 70 files. It's get pretty hard to maintain all this code without following some "best practices" I'm trying to create as much functions as possible (because of duplicate code) and constants (frequent changes) bud it doesn't seem enough.

I have generally this types of functions:

• Some general functions (insert text with logging, select or read from combobox.. )
• Some screen specific functions (fill one form.. )
• Some data/logic function - testing of app logic and data processing
• Test case functions - combines previous 3 to implement some test scenario

AutoIt does not have classes => no inheritance => OOP principles are hard to aplicate ( :D clearly)

Does somebody have some experince with larger applications written in AutoIt? My opinion is, that AutoIt is for scripts < 500 lines and it wasn't good choice for this big project.

It's a shame, that AutoIt doesn't have some useful IDE.

Valencia

Answer 1

AutoIt developers want to make sure that any functions written in AutoIt that are part of the core library (in short: UDFs) are subject to a certain code style. You can find this standard here: http://www.autoitscript.com/autoit3/udfs/UDF_Standards.htm Many programmers in the community write all AutoIt code in this standard.

On the subject of IDE. SciTE is a time-tested code editor, but as IDE it performs adequate. There are two other IDEs which are developed and maintained by the community:

• A graphical debugger (F10 step next functionality) http://www.autoitscript.com/forum/topic/21834-graphical-autoit-debugger/

• ISN AutoIt studio http://www.autoitscript.com/forum/topic/136766-isn-autoit-studio/

The last one is fairly new, but it looks extremely promising and it may work better for your project.

Finally, I have a note of warning. You say "OOP principles are hard to apply", but even as an OO programmer you should have a strong core idea of how to write non-OO code before you even learned OOP. Most OO languages are imperative at their core, so you should be an excellent imperative coder already. AutoIt is imperative as well.

A useful IDE will not solve your problems! But it will make them slightly easier to manage.

I don't know where you heard that AutoIt only performs well for scripts for under 500 lines, but every time you #include one of the default libraries you are adding ~10000 lines of code. If you can write proper code, you will build your own libraries without adding complexity to the rest of your code.

Heterologous

In addition to the official AutoIt standards page, there is this page that is slightly more detailed and expands on some aspects. Edit: Just to add, I have personally written AutoIt projects in the region of 5000 lines, and others have written even larger ones. – Richards

+1 ISN AutoIt looks real nice. @Valencia you should see how many lines ISN AutoIt was made in. It was made purely in AutoIt! – Abortion

Answer 2

As AutoIt doesn't have (as you mentioned) the enabling characteristics of an OO language I think part of an answer here is to look at what AutoIt has and what paradigm best fits it. It's clear to me that AutoIt is a language meant to done using procedural programming methods. For me, it's actually a bit of fun to go back to those methods that way of thinking. My large programs end up, with an an emphasis on correctly defining computation modules, what is passed into the module (and returned). If you are severely missing OO benefits I think the next thing to focus on would be scoping -- trying to keep that as tight as possible.

As a final note, I think using the procedural programming techniques does usually end up creating a separate task of re-factoring after the functionality is up and running.

A place to start...but this was the dominant paradigm for decades

Sublapsarianism