Seperating out code

[pink]

I have an app which uses a lot of the same code regardless of which card I am on, so at this point, the stack script is huge

Obviously, that is getting to be a pain when I am trying to do any editing, I have to sift through one big script, I would like to break it up into 6 six logical chunks of code, but still be able to access it from anywhere

Are there any downsides to creating a number of substacks which I would then use with "start using stack"?

other options that I see at my disposal are:
1. the call command, to call handlers from somewhere else... would this work with functions as well?
2. the insert script command, although I am not sure it is appropriate, it seems to me that its purpose is to override handlers instead of adding them

[zaxos]

make invisible buttons and add your code there, then call the code in your button

Code: Select all

send mouseUp to btn "Button1"

or if it is a function:

Code: Select all

send myFunction(var1,var2) to btn "Button1"

or if its not a function but needs extra params:

Code: Select all

send myCommand & "var1" & "var2" to btn "Button1"

[dunbarx]

In the old days, HC had a 30K limit for both field and script lengths (both were based on textEdit). It was often necessary to migrate code to other objects because authors simply ran out of room. I did. The backGround was a common place, if available and pertinent.

But the logical place for code that spans cards is the stack. Certainly you can move stuff to other stacks in use, backScripts, whatever, but to me, this seems even more removed and remote than having to find one handler among many. Just to see, open the script of the debugger:

edit the script of stack "revdebugger"

Is your script bigger than this one? You can see all the handlers in the left pane, and navigate at will.

I assume that you are not talking about individual handlers that are very long, rather lots of handlers in the same script. But if you are, can you create "subHandlers" or migrate self-contained code into functions that might reduce the length of those long code sets? Of course, this is normally done to make your code accessible to lots of objects sitting in disparate places, but it also can reduce the sheer length of handlers for that purpose alone.

Craig Newman

[jacque]

I frequently put most of my handlers in the stack script when they need to be shared across cards, there's no technical problem with that no matter how long they are. But if you want to divide the script just for ease of maintenance, backscripts are a good way.

Inserting a backscript is almost identical to "start using". It doesn't override handlers. (Frontscripts can do overrides if written to do so.) You can store the script in any object and insert it into back on preOpenStack or as needed.

Using substacks and inserting scripts with "start using" would be fine too, and almost identical to the backscript method.

I wouldn't use the "send" method, it has a large overhead and requires the engine to compile the line every time it's used. You'll get much better results with a backscript.

[MaxV]

Do you keep open the side window of the editor?
I worked with very long scripts, without any problem using it. It shows you in which function/handler you are:

[jacque]

One large project of mine has almost 100 handlers in the stack script. I like to keep them organized by functionality. There's a trick you can use to create "headings" in the side list so you can find the categories easily, either by sight or by using the Find box to look for the category name. Make empty handlers whose names begin with a series of underscores, like this:

on _____NAVIGATION_____
end _____NAVIGATION_____

on _____DATA_____
end _____DATA_____

In the left-side handler list, these will show up as category headings, like this:

_____NAVIGATION_____
preOpenCard
openCard
...etc

_____DATA_____
getPrefs
setPrefs
calcUserStats
...etc

You can click on the "heading" in the side bar to jump to that part of the script, or use the Find box to search for "_nav" and jump to it that way.

EDIT: I was wrong. I just checked and my big script has 159 handlers.

[pink]

These have all been helpful suggestions.

My big issues was less to do with the number of handlers, and more to do with a single handler that is 3000 lines and growing (it is one ginormous switch statement).

Moving that into its own substack has returned my code to a much more readable/scannable format.

One note for others who read this post, need to declare your variables again in the new substack script! Took me a few swings before I figured that out.

Thanks everyone!

[jacque]

Any code that runs correctly is fine, but my gut tells me that a handler that long could almost certainly be pared down. I don't think I've ever seen a single one that long.

[pink]

my program is taking a massive ascii file which represents my company's outbound phone records and does a bunch of things (tallies and whatnot) based on what the final status of the call was. So the script looks like this:

Code: Select all

switch lastStatus
     case 1
         add 1 to status["NoAnswer"]
         add 1 to livecount["live"]
         break
     case 2
         add 1 to status["Busy"]
         add 1 to livecount["live"]
         break
.......thousands of lines later
     case 952
         add 1 to status["MidTermAbnormal"]
         add 1 to livecount["dead"]
         if clID is "6349" then put lineQZ of phoneRec after field "abnormal" on card "client6349" of stack "Phoneageddon"
end switch

not really the code, but basically it (trying to remember it off the top of my head)
stack name is real

if you're asking yourself, is there really 952 different ways to classify the end of a phone call? the answer is "no... actually there's more..."

[jacque]

I see. I guess there's exceptions to everything.

I'd probably put a lookup list into a custom property though, which would reduce the code to just a few lines.

[FourthWorld]

Good to see you here, Greg:

My big issues was less to do with the number of handlers, and more to do with a single handler that is 3000 lines and growing (it is one ginormous switch statement).

One of the two most helpful books on software engineering I've read is Steven McConnell's 'Code Complete' (the other is his 'Rapid Development'), where he covers a lot of good ground on structure, factoring, style, and more:
http://www.cc2e.com/Default.aspx

One old rule of thumb that's been floating around the programmersphere for a while is that "A function should never be longer than can fit on your screen".

Of course that may not always be practical, esp. if you move between different monitors frequently. But the principle is sound enough, encouraging us to keep functionality into bite-size chunks where the logic flow can be more self-evident.

It may be helpful to keep in mind that the overhead of calling a separate handler over using in-line code is very minimal, even in LiveCode (about 0.000179 ms on my old 2.26 GHz Mac; 0.00009 ms on my custom 3.0 GHz Ubuntu box).

So you may be able to turn that monster switch into a nicely-flowing form by breaking out each case block's code as a separate handler.

Sometimes we need absolute-best performance, and in-line code can help with that. But only a very little bit, given the speed with which LC can jump to another handler.

In most cases, your development time in writing and maintaining the code is far more valuable than the sub-nanoseconds you might save with lengthy in-line blocks, deeply-nested IFs, or other things that often cause us to scratch our heads when we return to the code years later.

Edit: Jacque's post came in after I first wrote this, and it's a gem: if there's a way to generalize the actions in a lookup table, you may be able to reduce the overall size of the code very significantly, and have greater freedom to expand the range of operations by just modifying the lookup table without having to modify the code.