良好的编程实践
前言
JMP 脚本语言 (JSL) 提供的脚本功能范围从自动代码生成（类似于宏记录器）到用于应用程序开发的集成开发环境。 与任何编程语言一样，将良好的编程实践应用于 JSL 项目将产生健壮且易于支持的脚本和应用程序。 因为 JSL 简化了常见的编程任务，所以对这些实践的需求很容易被忽视或忽略。鉴于 JSL 提供的强大功能和灵活性，忽视良好的编程实践会使用户面临潜在风险。 编写这个简短的文档是为了让您了解这些风险，并提供您可以用来管理它们的编程策略。
一般最佳实践
- 始终从书面计划或问题陈述开始，并使用它来构建清晰可交付成果的清单。这些有助于防止范围蔓延并保持项目正常进行。
- 在可能的情况下，使用现有的结构（函数、预制代码、库等），而不是从头开始设计所有东西。
- 虽然通常不可能测试所有可能的输入情况，但应该使用多个输入条件。 还应针对 JMP 的预发布版本进行测试。 如果可能，应使用一组已保存的测试文件或一组书面测试条件（例如，对话框设置）。
- 应创建继任计划，明确当原始创建者不再负责维护代码时谁将负责代码维护。
脚本结构
- 无论您是单独开发代码还是在团队中开发代码，都建议从样式指南开始工作。 该指南应包含变量和函数的命名约定、编码元素周围的间距（即格式）、注释等信息。 该文档导致脚本和应用程序之间的一致性更高，使它们更具可读性和可维护性。 可以找到示例链接这里.
- 脚本顶部应包含注释部分，其中包含版本号、作者、修订日期、必需和可选输入、先前版本的错误修复和测试的 JMP 版本等信息。 每次修改脚本时都应该更新它，以便保留更改的历史记录。 还应包括对程序行为的简短描述，包括范围和限制。
- 注释应该添加到数据结构、控制流或逻辑的选择不是很明显的任何代码部分。
- 变量不应在最初定义它们的脚本/函数/块之外定义。 除非绝对必要，否则应避免使用全局变量。 应该使用 JSL 范围功能来实现这些限制。
- 只要有可能，脚本或应用程序功能应该被分解成小的独立代码块。 该代码可能存储在单独的文件或 JSL 数据结构中。
交货方式
- 考虑使用存储库、版本控制系统等来管理代码集合并确保用户可以访问脚本的最新版本。
- 在可能的情况下，应将代码打包以便于使用。
- 对于大中型应用程序，插件是完整解决方案的首选
- 除非您完全确定插件将普遍兼容，否则请使用插件向导中的最低 JMP 版本和支持的主机功能来防止插件在不受支持的环境中运行。
- 对于大型项目，应在插件中使用 JMP 应用程序以防止加载时间过慢。
- 未打包的 JSL 脚本应保留用于函数库、处理脚本、开发工作等。
- 最终用户不能编辑或查看的代码（以 JSL、插件或应用程序形式）应该被加密。
- 用户不应该普遍运行的代码应该已经运行加密。
其他注意事项
- 考虑在代码中包含许可或法律免责声明。 如果代码是公开发布的，组织可能会要求它们。
关于本文档
问：材料在哪里？
答：你正在读它。 
它目前仅在内部可用。 这将改变。
问：我们的动机是什么？
答：为了解决以下客户问题，无论是真实的还是感知的：
我的脚本不适用于最新版本的 JMP。
问：我们希望完成什么？
A：虽然我们无法控制引入新问题的情况，但我们可以提供指导，避免自己造成的问题。
问：文件是/不是什么？
答：当前文档旨在概述良好的编程实践。 它是描述性的而不是规定性的。 后者可能会晚一些。
问：我们需要您提供什么？
答：请告诉我们：
- 如果文件中有任何遗漏或不清楚的地方。
- 你认为接下来应该发生的事情。
- 您相信这一点的地方，以及未来的信息应该存在的地方。
- 您需要我们提供什么来将您的客户与脚本一起迁移到最新版本。
回复：良好的编程实践我将添加一个名为 Script Development 的部分，部署方法中有几件事可以包含在 Script Development 中（即存储库和版本控制）。除了部署方法中列出的加载项外，您还可以提及其他部署方法 - 在数据表中、独立脚本、在打开函数上运行、使用 windows 任务调度程序运行、日志中的脚本来管理工作流。 脚本开发可以包括从报告中保存脚本（以及 JMP 16 中的日志！），以及一些基础知识，例如如何将已从报告和 New Window() 中保存的脚本拼接在一起，以及脚本索引、JMP 等资源社区等...
