I’m an infrequent user of Applescript and just returned to it recently after a 10 year absence. I have recently written a couple of fairly complex scripts. One takes 45-60 minutes to run. The other takes 15-30 minutes.
I’ve just gotten them to run using osascript and now I’ll move them to cron and have cron run the osascript commands. But as it is I need to put in two entries, one for the first script and one for the second.
So my question is specifically: is it better to split complex scripts into a number of smaller scripts, and more generally: is there such a thing as Applescript Best Practices? I have read “Applescript: The Definitive Guide” and that’s given me some good ideas. But it doesn’t seem to include something more general, like “When scripts reach more than 500 lines consider breaking them into two scripts.” Does anyone know of such a thing? Google turned up zilch.
In my specific situation one script has Photoshop convert 100s of jpgs to tiffs, resize them, rename them and move them to another folder. Another script calls perl to parse a text file and create a new text file that is used as the basis for text entries in text boxes on 15-20 Quark pages that are created. The photos from first script are pulled into photo boxes on same pages. Then finished pages are moved to newly created folders and all photos called on those pages are also put into folder for specific page. Eventually all of this is moved to another server.
Logically it made more sense to me to do two separate scripts since the operations are somewhat different. But now that I’m going to be putting all of this in cron I wonder if it makes more sense to put all of this in one giant script, or perhaps call the second script at the end of the first script. And that’s where I can find no accumulated wisdom at all…
Best practices in AppleScript are much the same as best practices in any language; learning good programming skills is orthogonal to learning to use a particular language. I’d suggest picking up a copy of Code Complete or The Pragmatic Programmer and giving that a read.
Actually I’d have to disagree, respectfully. I’ve read much of Pragamatic Programmer, and though I found it useful I don’t recall much that has much impact on my Applescript coding.
Perhaps I should rephrase the question to “Is there a document for Applescript similar to ‘Perl Best Practices’?” I find both Perl and Applescript similar in that they both allow you to accomplish something very quickly. But my experience shows that both are laden with traps/frustrations/quirky behavior. “Perl Best Practices” is a complete book of what a very talented Perl programmer, Damian Conway, has to say about writing good, maintainable, efficient, comprehensible Perl code and avoiding the many traps, pitfalls, bad practices that are often found in Perl code. I’m looking for similar guidelines for Applescript.
Hanaan Rosenthal’s “AppleScript” book has a very nice section on Healthy Scriptwriting Practices and throughout the book pushes the benefits of breaking up long scripts into series of subroutines and objects. Fantastic book all around, best one out there IMHO.
I found CC very useful myself when moving from casual AS ‘hacker’ to halfway competent ‘programmer’. Though if you’ve read PP then I’m guessing you’ve already got some background in programming and this is all old advice to you.
Ah, that’s easy. Nope. The AppleScript market’s a fraction of size of the Perl market with relatively few professional programmers, so the titles you do get tend to target the language basics, or are specialist books on automating high-end apps such as InDesign. Some of the better general titles may discuss coding practices a little in amongst the rest of the content, but that’s about all you’ll find that’s AS-specific. You have to go to the general programming literature to learn beyond that. That’s life in the trenches for ya.
Best you can do is learn the language and principles of application scripting really well, read around the general CS literature for general programming advice, and put the two together yourself. Takes a bit more time and work, but it’s doable. For example, good advice on when and where to modularise code (procedures, modules, OOP) are the same for AS as other languages, but while the AS literature may cover the language features used, you’ll need to go to general CS literature to learn about concepts like coupling and cohesion to learn how to use them effectively. Variable naming rules are the same with the added caveat that you need to be extra careful of keyword collisions, which you’ll know to expect if you’re familiar with the AS language. AS-specific optimisation techniques, such as getting a single Apple event to operate on many application objects at once, are something that should be covered by the better AS books, while the theory (when to apply optimisations, how to do big-O calculations, etc) is covered on the CS side. Common gotchas may be discussed all over the place. And so on.
I’ll second this suggestion. Not only is the book highly informative, but it is well written and even entertaining by spells. It really does cover all the bases.
I’d been wondering about the Rosenthal book. Though I’ve seen good reviews somewhere or other didn’t know whether to trust them. Since you both recommend it as well I’ll take a look at it.
Hhas, thanks for your thoughtful advice. Since I’m only an occasional AS programmer I was hoping that I could live through someone else’s “life in the trenches” and just get the benefit of their experience without going through the trouble myself:-) I guess that won’t be the case. After I’d responded that I couldn’t recall how PP was relevant to AS I realized that sometimes you forget what is in books if you already know it. So perhaps PP had relevant info on modularizing code that I’d just forgotten about. Using the concept of modularization then it really does make sense to put the two separate scripts into cron. And this really is more of a CS question than a AS one as you suggest.
I should add that my question was also pushing for some sort of Applescript best practices document/web site if it didn’t already exist. Easier said than done I realize but it seemed like something worth mentioning to the AS community.
Since I’ve only read parts of PP (and that a long time ago) I couldn’t honestly say. Though I do know CC has quite a bit on this sort of thing and certainly helped firm up my knowledge. The other things that help are examining existing code (studying good code is useful for obvious reasons, but figuring out how bad code could be improved is also a very helpful exercise) and - of course - practice, practice, practice.
Really, you go with what suits your needs best. It’s all about keeping code well organised so you can follow what’s going on and don’t end up buried by complexity. Personally I dislike scripts over a few hundred lines long so tend to modularise quite heavily even where reuse isn’t an issue - makes it easier to see what each part does and how it relates to others. Some folks may have a higher tolerance for complexity so don’t feel the need to physically split it up as much. Knowing where and when it’s good or bad to divide code into separate blocks is the real trick, of course, and that’s where the CS theory - plus plenty of practice - comes in. There are some hard limits to the amount of code you can have in a single AppleScript, but they’re pretty high and I doubt you’ll ever hit them if your code is properly organised to begin with.
To be honest, I doubt there’s enough ASers who are sufficiently CS-literate and have time to burn for that to happen. Most ASers probably aren’t that concerned about all this high-falutin’ ‘Real Programming’ stuff anyway, and those that are interested can always step outside the AS sphere to learn it. FWIW, you might like to check out AppleMods, which is where my own AS modules reside these days; most are fairly well written and they’re all open source so you can easily poke around to get an idea of how they’re constructed.
Yes I suspected that a large proportion of AS scripters weren’t concerned with the high-falutin stuff. On the other hand it SEEMS to me from my very new Mac perspective that more unix types have entered the Mac fold and so there might be more interest in ‘real programming’. I do think it’s interesting that there’s more than 5 current books out on AS. That’s a whole lot more than when I last used it 10 years ago.
Thanks much for pointing me to the AppleMods site. It looks like that may be very useful.
