良好的編程實踐
前言
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 等資源社區等...
