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 [EMAIL PROTECTED] Computer programming ************************************** _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
