Preamble
JMP Scripting Language (JSL) offers scripting functionality that ranges from automated code generation (similar to a macro recorder) to an integrated development environment for application development. As with any programming language, the application of good programming practices to JSL projects will result in scripts and applications that are robust and easy to support. Because JSL has simplified common programming tasks, the need for these practices is easy to overlook or ignore. Given the power and flexibility JSL offers, disregarding good programming practices exposes users to potential risks. This short document has been written to make you aware of these risks, and to provide programming strategies that you can use to manage them.
General Best Practices
- Always start with a written plan or problem statement and use that to build a check-list of clear deliverables. These help prevent scope creep and keep the project on task.
- Where possible, use existing structures (functions, pre-made code, libraries, etc.) instead of engineering everything from scratch.
- While it is often impossible to test all possible input situations, multiple input conditions should be used. Testing against pre-release versions of JMP should also be conducted. When possible, a saved set of test files or written set of testing conditions (e.g., dialog box settings) should be employed.
- A succession plan should be created, making explicit who will be responsible for code upkeep when the the original creator(s) are no longer responsible for maintaining the code.
Script Structure
- Whether you develop code alone or in a group, it is advisable to work from a style guide. The guide should contain information such as naming conventions for variables and functions, spacing around coding elements (i.e., formatting), commenting, etc.. The document leads to more consistency across scripts and applications, making them more readability and maintainability. Links to examples can be found here.
- A comment section should be included at the top of the script with information such as version number, author, revision date, required and optional inputs, bug fixes from previous version and JMP version tested against. It should be updated each time the script is modified so that a history of the changes is preserved. A short description of program behavior including scope and limitations should also be included.
- Comments should be added to any section of code where the choice of data structure, flow of control, or logic is not immediately obvious.
- Variables should not be defined outside of script/function/block in which they are initially defined. Global variables should be avoided unless absolutely necessary. JSL scoping functionality should be used to implement these restrictions.
- Whenever possible, script or application functionality should be broken into small independent blocks of code. That code may be stored in separate files or JSL data structures.
Delivery Methods
- Consider using a repository, version control system, etc. to manage collections of code and insure users can access the most current version of a script.
- Where possible, code should be packaged for ease of use.
- For medium to large applications, Add-ins are preferred for complete solutions
- Unless you are completely sure the add-in will be universally compatible, use the Minimum JMP Version and Supported Host features in the Add-in wizard to prevent the add-in from running in unsupported environments.
- For large projects, JMP Applications should be used within Add-ins to prevent slow load times.
- Unpackaged JSL Scripts should be reserved for Function Libraries, processing scripts, development work, etc.
- Code (in JSL, Addin, or Application form) that the end user should not be able to edit or view should be encrypted.
- Code that users should not be universally able to run should have run encryption in place.
Other Considerations
- Consider including licensing or legal disclaimers with the code. They may be required by an organization if the code is being posted publicly.
About this document
Q: Where are the materials?
A: You're reading it. 
It's currently only available internally. This will change.
Q: What is our motivation?
A: To address the following customer issue, whether real or perceived:
My scripts won’t work with the latest version of JMP.
Q: What do we hope to accomplish?
A: While we can’t control cases where new problems are introduced, we can provide guidance for avoiding self-inflicted problems.
Q: What is/isn’t the document for?
A: The current document is meant to be a general overview of good programming practices. It is descriptive and not prescriptive. The latter will likely come later.
Q: What do we need from you?
A: Please let us know:
- If there is anything missing or unclear in the document.
- What you think should happen next.
- Where you believe this, and future information should live.
- What you need from us to make the process of moving your customers with scripts to the latest version.
I would add a section called Script Development and there are several things in Deployment Methods that would make sense to include in Script Development (ie, repository and version control). Along with add-ins listed in Deployment Methods, you can also mention other deployment methods - in the data table, stand alone scripts, run on open function, run using windows task scheduler, scripts in journals to manage workflows. Script Development can include things like saving scripts from reports (and the log in JMP 16!), and a couple of basics like how to stitch scripts together that have been saved from reports and New Window(), resources like the Scripting Index, JMP Community, etc...
