Making the move...

[Geoff Canyon]

This sounds like a bunch of small handlers masquerading as a large  
handler ;-)

Nothing wrong with that, I just think it means that you're really on  
my side of the big/small question, except that you don't like the  
surplus of handler names it leads to. I can certainly agree with  
that. Every time I've ever advocated small routines, I've mentioned  
as one of the caveats that you end up with that many more handlers to  
keep track of. As you say, if the task is never called separately,  
and you break it out within the larger handler, and you document it,  
it's not that big a deal. I'd argue that if you've done all that you  
might as well break it out as a separate routine, but I think we've  
reached the pot-ay-tos, pot-ah-tos stage of the discussion.

gc

On Mar 20, 2006, at 1:38 AM, Chipp Walters wrote:

> Hi Geoff,
>
> One does come to mind, it's the startup handler(s) of my splash  
> stack, and they are broken down serially into 7 or 8 different  
> handlers, each numbered sequentially with a handler name.
>
> And because I want to be able to read them one after the other, I  
> ended up programming them serially. Some were as long as 50-60  
> lines, others shorter. Because they form the code of virtually all  
> of my applications, I wanted them to be very easily read, and updated.
>
> This worked for me. May not have for you, I don't know. I doubt my  
> brain can grasp thinking in bigger chunks..it's working overtime as  
> it is!
>
> -Chipp
>
> Geoff Canyon wrote:
>> Out of curiosity, do you have an example handy of a long handler  
>> that  you think makes more sense to keep together than to break  
>> up? Or one  that you think can't be broken up without significant  
>> effort to do it?
>> When you think of a long handler, do you generally think of it as   
>> having a single identifiable task, or do you think of it as being   
>> several tasks performed in sequence in one handler?