When I have a longer script it is difficult to line up steps to find out indents in the script.  I mean like when there is loop and If and I am told I am missing an end loop or an end if.  Do you all know what I mean?  Is there a plug-in or tool I can use which draws a line down each of the indents so they are easier to see whether a step is in the first, second or third indent?

This is about as close as you'll get: http://www.freewebs.com/russellwatson/fmworkmate.htm

 

In general though try to keep your loops and IF..END IFs short, break out long chunks of code in subscripts.  Much easier to wrap your head around.

 

And do simple things like avoiding:

IF[ something = true]
  many lines of code
  more lines of code
  even more code
END IF

and go for something like this, that minimizes the level of indents

IF[ something = false]
  exit script
END IF
many lines of code
more lines of code
even more code

One of my hopes with FMP14 is a better IDE for scripts.

Personal annoyance: you're messing around in a field calculation, and press Command-Z to undo. Instead of undoing the last thing you just did, it reverts the complete calculation to what it was before you started. Argh!

Mike, that's expected behavior. Frustrating, yes.

 

In general though try to keep your loops and IF..END IFs short, break out long chunks of code in subscripts.  Much easier to wrap your head around.

 

 

A million times, this.  A trick with organizing subscripts is to indent them using spaces, and put them just below the master script in the script organizing.  That way, you know that the "X" number of scripts you're looking at are in fact one "mega" script, where the primary script calls each of the sub-scripts at some point. 

 

Of course, this also helps with development.  A good practice is to figure out the general logic for a script, without worrying about how you're going to implement each piece.  And then implement the pieces one by one, making sure that one works before going to the next one.  Obviously this only works when the pieces are more or less standalone, but makes for a lot easier testing.

 

As one example that I finished up this past week, we generate a form with some XML and text file magic from data in various records.  For a given part of the form, there are up to two things that may have to be added: US and non-US stuff.  So I just  had a simple if "US"/else if "non-US"/end if block at first.  Nothing was actually done, while I made sure the rest of the script worked.  I then did the US stuff, and once that was working, did the non-US stuff.  Made testing a lot easier.

A trick with organizing subscripts is to indent them using spaces, and put them just below the master script in the script organizing.  

 

 

I never do that.  A subscript can be re-used many times in different contexts, it can be a subscript of another subscript in another workflow.  So I don't try to convey meaning by using spaces in the script name to indent it.  That's unnecessarily restricting IMHO.

I never do that.  A subscript can be re-used many times in different contexts, it can be a subscript of another subscript in another workflow.  So I don't try to convey meaning by using spaces in the script name to indent it.  That's unnecessarily restricting IMHO.

 

Definitely depends on the subscript in question, for sure.  Some subscripts I have are very, very particular to the calling script, and indeed are subscripts only so that the calling script is more readable during editing.  I do have other subscripts that are more "building block" scripts called by a multitude of different scripts, and I don't do the indentations for those.

Definitely depends on the subscript in question, for sure. 

 

 

I don't think it does. I've seen this type of "classification" in action for the last 10 years or so and more often than not it leads to reluctance to re-use a subscript because it is  marked as somebody else's subscript, ultimately leading to duplication of code and maintenance and debugging issues.

 

There really is no point in trying to classify a script as a subscript of another script.

There really is no point in trying to classify a script as a subscript of another script.

 

This all makes sense thank you for your examples Wim.  It seems that I have named a script as 'TRIGGER: Script Name' and then later I realize it would come in handy as a regular script and I wish I hadn't added the 'trigger' part to it.  

 

Another example is naming it the trigger type such as OnLayoutEnter.  Question then is, if I drop the reference to it being a trigger, I would still read it before using it as a regular script so why "tie" a script to an action anymore than tying it to a main script?  I have been debating these things for quite some time now.

 

Thank you for the link.  By using color on my If and End If and a different color on Loop and End Loop, it is now fairly easy to tell the indents although a grey line down the script would still help.  I also really like your example on post #2 above and will use it in future.

I don't think it does. I've seen this type of "classification" in action for the last 10 years or so and more often than not it leads to reluctance to re-use a subscript because it is  marked as somebody else's subscript, ultimately leading to duplication of code and maintenance and debugging issues.

 

There really is no point in trying to classify a script as a subscript of another script.

I will agree to disagree! :)

Are you serious?

This all makes sense thank you for your examples Wim.  It seems that I have named a script as 'TRIGGER: Script Name' and then later I realize it would come in handy as a regular script and I wish I hadn't added the 'trigger' part to it.  

 

Another example is naming it the trigger type such as OnLayoutEnter.  Question then is, if I drop the reference to it being a trigger, I would still read it before using it as a regular script so why "tie" a script to an action anymore than tying it to a main script?  I have been debating these things for quite some time now.

 

One thing you can do for triggers is to keep one script that does the logic and call that script in a dedicated Trigger script (a wrapper script) that you can then name with the proper "trigger" prefix/suffix.  That allows you to re-use the logic in other non-trigger scripts, and add trigger-specific logic to the wrapper script if needed.