on 2013-03-03 22:13 LuKreme wrote
In our previous episode (Sunday, 03-Mar-2013), steve harley said:
philosophically, i use "early exits" a lot to save time and avoid excess
structure (depending on the language, too);
Ah, I am just the opposite then. I will add structure to make things as clear
as possible, so I am far more likely to write
if false then
do this
else
do that
end
even if do this or do that are empty, just in case I need that logic block
later I find it is much simpler to see what I did and add code in the right
place than try to tack on that structure later on.
these are age-old questions, but the question of general structure is different
from that of early exits; just for fun i asked the internet and found this
thread that provides some good point/counterpoint:
<http://programmers.stackexchange.com/questions/18454/should-i-return-from-a-function-early-or-use-an-if-statement>
_after_ the early exits, i do generally follow structured programming norms,
but i don't use empty elses
however since i have only one early exit here, what i did seems superfluous;
maybe there were some other tests there before, but now it might as well be:
if the_choice is not false then
… rest of block
Ahhhh! run away!
i try to ignore AppleScript's Englishishness; the fact is, choose from list
returns either false (instead of throwing an error like every other choose
command) or a list, so you have to check the type or force it to throw an error
indirectly; other ways to do it, but also with trade offs:
if class of the_choice is list then
… rest of block
and:
try
set the_choice to item 1 of the result
set user_canceled to false
on error
set user_cancelled to true
end try
if not user_cancelled then
… rest of block
i think the intuitiveness (to me at least) of false meaning the user canceled
overrides the awkwardness of the apparent double-negative
py-appscript is a much more expressive way to do what AppleScript can do; it's
really too bad Apple has shelved the APIs it relies upon
_______________________________________________
MacOSX-talk mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/macosx-talk
