Good coding practices in AutoIt

[MarkRobbins]

....WHAT?! There were static variables in AutoIt all this time?!!? I wish I'd have known this sooner! It would have saved me a lot of work.

 

Huh, well if we have local statics, we dont need globals!

Func G($name,$val=Default)
  Local Static $x, $y, $z
  If @NumParams==2 Then
    Return Assign($name,$val,4)
  Else
    Return Eval($name)
  EndIf
EndFunc

G('z', 'zebra')
Local $a=G('z')

MsgBox(0,'z',$a)

[guinness]

Huh, well if we have local statics, we dont need globals!

Func G($name,$val=Default)
  Local Static $x, $y, $z
  If @NumParams==2 Then
    Return Assign($name,$val,4)
  Else
    Return Eval($name)
  EndIf
EndFunc

G('z', 'zebra')
Local $a=G('z')

MsgBox(0,'z',$a)

This has been discussed before in this thread. Also you're using 'magic numbers' which also has been discussed. 0 = $MB_OK.

[MarkRobbins]

This has been discussed before in this thread. Also you're using 'magic numbers' which also has been discussed. 0 = $MB_OK.

 

Good point, and I can always get rid of the magic number in Assign by.... creating yet another Global Const

I will have to finish reading the thread first, I want to hear about all the downsides, particularly if they are voiced with consternation.

[guinness]

Assign, Eval and IsDeclared have their uses, that's not it. Please do read.

[MarkRobbins]

I use globals, else I may not bother to finish the program.

I don't think globals are bad at all, and my local friends who argue that global is horrible programming practice, don't program anything.

So their opinion is not valid to me.

I am very clear that I can run into trouble with globals, but they can also save me time.

EDIT:

Namespace is the first problem using globals that comes to mind.

I try to use local of course.

 

I would say that a balance is struck -- If you are doing something quick, small and dirty, you can throw up a lot of globals and then refactor them out when you start seeing a pattern.

On the other hand, keeping globals down is like reducing the public interface when designing a class, unless you are creating a library then you operate on the YAGNI principle and do not code for completeness.

As code matures, I would say you could analyze the globals and package them, taking into account on access intensity you could put them in getter-setter functions as local statics.

That can give needed structure to whats going on.

But hey, maybe I'm just wrong.

 

[MarkRobbins]

Model - View - Controller

 

 

MVC rocks. Take a look at PureMVC, its language independent (kinda sorta). I did an enhanced port of it to C# and to ActionScript. What is missing from your post is the 'Facade' which operates both like the 'Program' class and the manager of the MVC entities. All entities register with the Facade, then they expose the message types they are interested in receiving. So Models and Views send messages, and the Facade is in charge of delivering them to subscriber OR invoking a Controller. M&V receive msgs too.

The Controller is stateless and transitory, it does its thing (its a verb/Command) and retires. Here is the key though, most of the application specific code resides in the controllers and Facade, they are the 'throw away' components as far as code reusability goes. M&V's become part of your library, but you can still rework controllers for future projects, or reuse them directly if they are generic enough.

It took me a long time to grasp the benefits of the whole system, but it is great. Loose coupling, no one knows anything about anyone haha. Hard to debug though and keep the event flow managed.

[MarkRobbins]

Assign, Eval and IsDeclared have their uses, that's not it. Please do read.

 

Sorry to bother, but I read the thread and must have missed references to those functions in the context of static locals. Can you give me a pointer or a rundown? Also, such a technique doesn't really have to rely on Assign and Eval if you are willing to write the dispatch.

Thanks.

[guinness]

Why didn't you just use search at the top and right Static to search in this thread?

Anway, took me 3 seconds>> 

[guinness]

trancexx is right when she says INI files are deprecated >> http://blogs.msdn.com/b/oldnewthing/archive/2007/11/26/6523907.aspx?Redirected=true

[Mat]

trancexx is right when she says INI files are deprecated >> http://blogs.msdn.com/b/oldnewthing/archive/2007/11/26/6523907.aspx?Redirected=true

 

Just says that the registry is preferred for all the reasons mentioned.

Ini files are still the best option for portable applications.

Registry isn't quite as simple as ini files either, there are a couple of extra bits you need to be aware of (like the x64 hives for example).

[Ascend4nt]

There's a few issues with choosing where to store data.  Windows recommends using the Registry in place of INI files, however, they note this is only for configuration and intialization data, and only up to a certain size.  See Registry Storage Space, Registry Element Size Limits.  There is another article I can't find, but it mentioned not writing more than a total of 1MB of data to the Registry.

There's quite a number of apps that defy these rules, most likely because Microsoft's website is often as inconsistent as their recommendations are.  I personally don't see why it's that big of a deal to use INI or other configuration type files (like '.cfg' or '.prefs' etc).  INI is great for portability (even across O/S's), and easy customization. You can avoid any Windows limitations by writing your own parser since the format is so simple.

[guinness]

I use Ini all the time as I'm a Portable fan. I've mentioned before that I do break the rules!

[FireFox]

Registry is like a garbage full of shit in my head. If I have to use it instead of inis it will take some time.

Edited August 1, 2013 by FireFox

[guinness]

I known some users (maybe AZJIO) have created Ini-like wrapper functions around the Registry functions to ease the pain.

[guinness]

It was worth a read at least >> http://www.tutorialspoint.com/developers_best_practices/developers_best_practices_pdf.htm

Edited August 23, 2013 by guinness

[BrewManNH]

That was incredibly painful to read.

[jaberwacky]

Because this is how we all beast out code.  =P

[guinness]

That was incredibly painful to read.

That's not a fair comment, given the fact their native language isn't English. I think the overall ideas were clear and they made some valid points too.

[Ascend4nt]

It was worth a read at least >> http://www.tutorialspoint.com/developers_best_practices/developers_best_practices_pdf.htm

guiness, I agree with most of what (I think) the writer was saying.  However, the 'accept criticism but don't criticize' remark I find issue with.. how else are we gonna tell other people that they are writing crap code? haha

Because this is how we all beast out code.  =P

jaber, wth.. where'd you get my picture?!  ah.. those were the days (pre-surgery)

[BrewManNH]

That's not a fair comment, given the fact their native language isn't English. I think the overall ideas were clear and they made some valid points too.

I disagree, trying to read that made my brain bleed. I couldn't get past the terrible spelling or grammar to get to whatever points he was trying to make. I stopped reading after the second page.