Good ways to overcomplicate your code and slow down development
dsc at swcp.com
Sat Sep 16 01:05:23 CDT 2006
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
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 Scott Consulting and Dar's Lab
dsc at swcp.com
More information about the use-livecode