On Mar 2, 2011, at 11:26 AM, Richard Gaskin wrote:
Andre Garzia wrote:
I tend to work on the same way. longer forms makes shorter
understanding
time. I'd rather write more and understand more than write faster
and then
one week from now, be completely lost in nested mazes
Well said.
And sometimes lengthy deeply-nested IFs are good candidates for a
switch block.
I once stumbled across two tips about code style that have been very
helpful:
1. If a given function has nested IFs more than three levels deep,
it may be a good candidate for breaking it up into smaller functions.
2. If a function is longer than can be viewed in one screen, it may
be a good candidate for breaking it up into smaller functions.
Sometimes those can't be applied for sound practical reasons, but
where they can oh boy does it make code more readable.
I grapple with this all the time. My status with LC is "dedicated
amateur," so I may not use the best practices, but.... One other
consideration is breaking out a chunk of code when it needs to be
reusable, but this is not without problems too.
I have a number of text-processing handlers that parse out various
context-sensitive options for constructing pop-up menus, inserting
text strings that are themselves constructed using various if-else-
then scenarios, etc, and these tend to result in very long handlers
with lots of conditional branching. I keep trying to break up my long
handlers into smaller chunks. What I run into is that to do this I
often face trying to construct functions that require 8-10 parameters,
which are cumbersome to call, since you have to keep careful track of
the order in which to list things in the calling statement. Whereas
within a long handler I can make use of multiple variables that
already contain pieces of data and make use of them without having to
pass them anywhere. I usually end up splitting off a chunk of code
into a function when I find that I need to use it a number of times in
different contexts. I end up with some handlers and functions that
require lots of parameters but can be called from many different
buttons, fields, menus, etc., in which case living with a long
parameter list is well worth it for the flexibility.
I have not yet found very many tricks to avoid long multivariable
handers, given that I'm trying to provide extremely context-sensitive
behavior. I do end up with some very sophisticated features, eg,
constructing a prescription for printing or just logging, checking to
ensure the med is not in the patient's allergy list, checking if a
telephoned prescription is a controlled drug and therefore needs a
faxed copy and if so then setting up a reminder to fax the copy (but
only if there is a fax number listed for the patient's pharmacy, if
not, then a reminder to get the fax number), logging the prescription
in the notes field and the current meds list, calculating and noting
the expected date the med will expire, loading the med into the
prescription history, and checking to see if a serum blood level is
(a) necessary and (b) overdue -- all with a mouseclick on the med
listing line, and a couple of keypresses.
It turns out that it is hard to break this kind of thing down into one-
page handlers, but I keep trying. I tend to use switch blocks for long
complex conditionals and if-else-then for the shorter conditionals,
but I'm fairly sloppy about when I do one or the other. But I almost
always construct if-else-then structures using the long form -- I
heartily agree that it is much, much more readable.
-- Peter
Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
