Re: What's good program design in applescript?
Re: What's good program design in applescript?
- Subject: Re: What's good program design in applescript?
- From: has <email@hidden>
- Date: Sat, 28 Sep 2002 11:34:32 +0100
Arthur J. Knapp wrote:
>
> Quite long article, after reading some of the sections, may I ask what9s
>
> good program design & maintainable code in applescript?
>
>
Are you TRYING to start a flame war? ;-)
Mff. Well me no bitey for one. Somebody else's turn. ;p
>
> Are handlers and script objects a must?
>
>
Script objects? No, not a *must*. They *can* make some complex scripts
>
more readable or maintainable, but they do not nessesarily do so.
You didn't specify modularity for improved reusability/code sharing
(libraries).
They're also the foundation for OO programming in AS, which can be a
valuable technique in solving a great many intermediate-to-advanced design
problems. (But unfortunately not well covered within the existing
AppleScript literature.)
>
Handlers, well, it depends on what you are doing. A large number of
>
AppleScript projects are very small, ie: many people create scripts
>
to do very simple actions. There is no reason to believe that using
>
handlers in such a script is going to make the script any more
>
"maintainable". The main point of a handler is to reuse the same bit
>
of code over and over again, possibly with different parameters.
Another advantage: handlers also give you a nice, well-defined interface to
test against. For example, a recursive file-naming script could have one
handler for file/folder traversal, and a second for text-munging. You can
stub the text-munger handler while you test the traverser handler works
okay, and you can test the text-munger routine in isolation using suitable
sample data. [1]
(There's bound to be plenty others too, but I don't see why I should do all
the hard work around here.;p)
...
To summarise a non-response to the original poster: your question shouldn't
be so much about WHAT you use, but about HOW you use it. Simply tossing
these structures into code won't make that code better, but they do make
constructing good code much easier. Good use of structures _follows_ from
good design, not the other way about.
One last suggestion, if you're serious about code design. Buy yourself a
copy of "Code Complete", by Steve McConnell (Microsoft Press). It's
extremely well written, clear and easily understood (even to an amateur
like me), and a real "page-turner" as programming books go. I don't think
you'll regret it.
HTH
has
[1] Another way of looking at this: design code so it'll be easy to verify
is correct. If it's hard or impossible to test, look to redesign it until
it isn't. Apart from anything else, life is MUCH simpler when you only have
[e.g.] 6*3^2 rather than 2^18 code branches to test.
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.