I agree, in general. But I just had this case where I wanted to display the ReleaseNotes to the user. If these are in a Comment, then I have to duplicate them in a Set Variable or Display Text action. Unless you have some other idea?
I don’t want to use Variables for this purpose as a standard. That’s not what they’re for.
If you want to do it on an individual basis, well, they’re more “guidelines” than “rules”, so that’s cool.
And if I write code to parse for version information, I suppose I could look in Set Variable actions also.
But I’m strongly opposed to use Set Variable for documentation. There’s this thing called “code smell”. And no, I’m not saying you smell, or your ideas smell. It’s a term programmers use for things that just don’t feel right. And this is one of those things that just has a “smell” to it, to me.
Of course, you’ve changed my mind before, so who knows, but that’s how I feel right now.
That’s a new term for me. But I get your point – it just doesn’t feel right.
However, in my experience, putting program information in variables is hardly new. I’m using “variable” here in the broadest sense to include properties, resources, support files, etc, that at some point the software may need to display to the user.
There are some very common use cases on the Mac:
File > Get Info
App > About
App > Release Notes
Help > lots of stuff
I’ve been using AppleScript script properties for this purpose for a long time:
Since these are at the top of the script, they serve the purpose of internal header comments. But then, if an error occurs, I can display these properties to help the user clearly identify where the error came from.
In fact, AppleScript has a built-in property called “version”, which I should really set. Other scripts can get the version of another script without opening that script.
Don’t most Windows apps have a similar approach?
So, my thought is that sometimes we might want to display Release Notes to the user. If we don’t put that in a variable, how would we do it?