How to organise code

[deadbug]

I'm plugging away at my first AutoIt GUI script.

I'm looking for suggestions on the best way to organise it.

If I put it all in one source file I end up with 1100+ lines, and I still have a few screens to go and I also need to write some actions (i.e. actually make it do something at the end of the day).

The alternative seems to be to have a main gui.au3 source that then includes all the other compartmentalised bits (basically one source file per screen, one for gui-related utils, one for file handling etc.).

So how does everyone else organise things?

BTW: am I missing a really simple way to create structures (or even objects)? Right now I have a function that creates a checkbox and a couple of input boxes and a pair of clickable folder icons. I have to feed it an array (by ref) to keep the ids in (for later processing) and I have to have enums to define what's what (this id for the checkbox etc.). A structure would be ever so handy here ...

Thanks for any pointers,

-- deadbug

[Hawkwing]

I always create GUIs with KODA FormDesigner (http://www.autoitscript.com/fileman/users/lookfar/formdesign.html)

Much easier!

Edited January 26, 2009 by pigeek

[Melba23]

deadbug,

I think coding style is as much a question of personal taste as anything - if it works and you can understand it when you look at it again after a period of time then it is fine. As to length, my longest script to date is 3000 lines with 12 AutoIt include files and 7 UDFs (mostly written by me). So size itself is not a bar to clear coding.

One of the many advantages of the full SciTE package (and perhaps the one installed with AutoIt, but it is so long ago that I used it, I cannot be sure it works there) is the #Region - #EndRegion directive. This enables you to break your code into regions that can be shrunk to a single line. It also forces you to compartmentalise your code - which can only help make it more understandable.

Personally I use a #Region system for all my AutoIt scripts (and something similar for all the programming I have done since I began 40-odd years ago) and a sample script would look something like this (each section is a separate region and, of course, not all are needed for every script):

SciTE Directives

Short comment on latest changes

Includes

Global declarations

Check if already running

System initialisation code

Read INI values

Read in needed files

Create tray menu

Create main GUI

Create child GUIs

Main GUIGetMsg Loop (I tend to use the GUIGetMsg mode as I prefer passing parameters rather than having lots of global variables)

Function 1 (these can also be further divided into regions if they are too numerous)

Function 2 (these can include further GUIGetMsg Loops if child GUIS are called)

...

Function n

Misc functions (these tend to be little bits of code that are used by many functions)

Help/Info

A word on comments. As has pointed out to me on several occasions, I tend to overcomment my code but I prefer to have too many comments to too few. Having had the dubious pleasure of trying to modify code written by an unknown predecessor who virtually never commented, I feel that my approach is the better. I am not suggesting that you comment every line - give the reader some credit - but make the logic and flow clear. You must explain where you could appear to have made an arbitrary decision - you may know why a certain value must be set just so, but will anyone else?

Sorry to be so long-winded, but like all things, if you can begin in the correct manner, it makes it so much easier later on.

Hope this helps. No doubt others will add their own thoughts - take what works for you.

M23

[deadbug]

I always create GUIs with KODA FormDesigner (http://www.autoitscript.com/fileman/users/lookfar/formdesign.html)

Much easier!

I did use Koda to start off, but then I found that where, for example, I have a checkbox that decides whether two inputs and their associated folder icons should be enabled or disabled, there didn't seem to be a way to tie all that together. I may have missed a bit (I only spent a few hours playing and using it to proto some screens) but I ended up tweaking bits here and there anyway. Plus it looked like the code size would shrink and be easier to understand if I pushed things down into functions.

I might go back to it - it was certainly useful in providing a starting point for my GUI.

Thanks

-- deadbug

[deadbug]

I think coding style is as much a question of personal taste as anything

I was careful not to wade in with "So, which is the best editor then"

One of the many advantages of the full SciTE package (and perhaps the one installed with AutoIt, but it is so long ago that I used it, I cannot be sure it works there) is the #Region - #EndRegion directive.

Ah, excellent. I'd completely missed that feature! Back to one source it is then (at least for now).

If I've missed how to have split screen viewing in SciTE, now's the time to tell me, please! (Opening a source file twice would work as long I can mark one as read-only ... otherwise you know what I'll end up doing!).

Thanks again,

-- deadbug

[Jos]

I have coded the #region support in the standard lexer that comes with SciTE and is available in any editor using scilexer.dll and supporting AutoIt3.

SciTE doesn't have a multi window option. The only thing you could do is have SciTE open an new session for each file in stead of creating tabs in the same session.

To have the option to be able to open a file twice you will also have to tell SciTE not to check for that.

Have a look in the SciTE documentation for the keywords to modify. (Ctrl+F1)

Jos