A curious case

[Peter Brigham MD]

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
pmbrig at gmail.com
http://home.comcast.net/~pmbrig