Good ways to overcomplicate your code and slow down development

[Dar Scott]

On Sep 15, 2006, at 10:37 PM, Chipp Walters wrote:

> I've tried writing code where no handlers/functions are more than a
> dozen lines long, and while it is an interesting excercise...it's a
> real pain to debug, not to mention to go back and try and figure out
> what the heck you meant to do 6 months from now.

I'm realizing people are different.  I'm not smart enough to do  
that.  I do the opposite.  In a sense, I look at the script 6 months  
from now and then write it now and then it turns out to be usually a  
dozen lines or so.  Well, some handlers with switches are a lot  
longer and many functions are one line.

Well, when I'm at my best.  Often I just get a big stick and whack at  
it and beat the whole script into shape.  In that case there is no  
telling what it is going to look like.

> Of course, if you are GOING TO USE the same functionality more than
> once, then by all means break it out into a function, handler or even
> library.

I agree.  Often we find we are scripting the same thing and that can  
be factored out.

Yet often the use of functions is not so much breaking up our scripts  
but something that emerges before scripts are written, or emerges  
when we realize we are going about something wrong.  Perhaps that is  
what you mean by functionality.  That is, we can see a repeated  
pattern in the script, but what we factor out is not exactly that but  
something meaningful, something that makes sense 6 months from now.   
If we are having trouble naming the custom command or the function,  
that might be an indication that the breakup is arbitrary.

We can consider Ken Ray's q() function for quoting a string.  All it  
does is return the parameter with quote marks around it.  It is not  
just something that Ken does a lot.  It is something that is  
meaningful to Ken.  It doesn't just save keystrokes; it doesn't just  
allow him to pack more into a line.  It helps creates scripts that  
are meaningful to Ken.  I'm pretty sure he doesn't use this in some  
arbitrary way just because it happens to put quote marks in certain  
places.  I expect Ken to use q() where he thinks of strings as  
quoted.  To Ken (and to most of us) this helps in reading his scripts.

Perhaps q() is an extreme example, but I think it is something we can  
learn from and it would be good to emulate.

Sometimes I make a collection of functions to help me work with a  
higher level when trying to script.  That collection thus tends to  
keep my handlers small.  In working on something small, say interval  
addition, I can focus on that without the stress of the big picture.   
When I get to the big picture, I have the tools to make it easy.   
Many go top down (and I often do that, too) and the idea is similar.   
Of course, at some level, I had to go top down to know what took  
domain I needed.

I think Robert Sneidar's style of scripting around comments of  
pseudocode does much the same as far as keeping things simple.  When  
expanding each line of pseudocode, Robert need look at only that  
pseudocode and how to connect to earlier code.  He need not try to  
grok the entire handler.

Perhaps how we script is an indication of something about who we  
are.  (Hmmm.  Maybe it was a mistake to mention the occasional  
whacking with a big stick.)

To be clear, I do often tackle very hard problems, problems some have  
considered complicated.  I'd hate to mislead people about that.  But  
I only solve simple problems.

Dar
--
**************************************
Dar Scott
Dar Scott Consulting  and  Dar's Lab

http://www.swcp.com/dsc
dsc at swcp.com

Computer programming
**************************************