《UNIX/Linux 系統管理技術手冊（第四版）》——2.6 腳本程式設計的最佳實踐

本節書摘來自異步社群《unix/linux 系統管理技術手冊（第四版）》一書中的第2章，第2.6節，作者：【美】evi nemeth , garth snyder , trent r.hein , ben whaley著，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視

unix/linux 系統管理技術手冊（第四版）

雖然本章裡的代碼片段幾乎不帶注釋，而且很少列印用法說明，隻是因為我們已經列出了每個例子的大綱，進而展現出若幹關鍵點。實際的腳本應該有更好的表現。有幾本書通篇就講編碼的最佳實踐，不過其中的基本指導原則如下。

如果運作腳本時帶了不合适的參數，腳本應該列印一則用法說明，然後再退出。更好的做法是，也以這樣的方式實作--help選項。

驗證輸入的有效性，并檢查獲得的輸入值。例如，在對算出來的一個路徑執行rm -fr操作之前，可能要讓腳本複查這條路徑是否符合期望的模式。此時會發現腳本程式設計語言的“污點（taint）”功能很有幫助。

傳回一個恰當的退出碼：0表示成功，非0表示不成功。但是，沒有必要非要給每種不成功的模式配置設定一個唯一的退出碼，考慮調用程式實際想要的是什麼。

用适當的命名約定來給變量、腳本以及函數起名字。名字要符合該語言的慣例，符合代碼庫中大部分代碼的習慣，最重要的是，符合目前項目裡定義的其他變量和函數的慣例。用大小寫或者下劃線來讓長名字可讀性更好1。

用變量名反映變量儲存的值，但要保持簡潔。number_of_lines_of_input這樣就太長了；試試用n_lines。

考慮形成一種指導風格，這樣一來，你和你的團隊成員都可以按照相同的規範來編寫代碼。有了這樣的指導，在閱讀别人寫的代碼，或者别人閱讀你寫的代碼時，都會變得更容易。

每個腳本開頭有一段注釋，說明該腳本的作用以及它接受的參數。注釋裡要包括作者的名字和編寫日期。如果這個腳本需要在系統上安裝非标準的工具、庫或者子產品，那麼也要把它們列出來。

注釋要達到的程度是，過一兩個月再來看這個腳本，發現注釋很有幫助就行了。有關注釋的一些要點如下：選擇的算法、沒有按顯然更好的方式去做的理由、代碼裡不常見的路徑，以及在開發期間成為障礙的任何東西。不要到處亂寫沒用的注釋；要假定閱讀代碼的人不傻，而且熟悉語言。

最好做到代碼塊級或者函數級的注釋。對變量功能的注釋說明應該出現在變量聲明或者首次使用變量的地方。

以root身份運作腳本是可以的，但要避免設定這些腳本的setuid位；保證setuid的腳本徹底安全相當費事兒。是以代之以用sudo來實作适當的通路控制政策。

對于bash來說，在執行指令之前，先用-x回顯指令，用-n檢查指令的文法，卻不執行它們。

perl的-w選項可以把某些可疑行為報告給使用者，如變量未設定就先使用這樣的問題。可以把這個選項加到腳本的“#!”一行裡，或者用use warnings打開該程式的文字提示。

在python中，除非在指令行用-0參數顯式地關閉debug（調試）模式，否則就在這個模式下。這意味着，可以在列印診斷輸出之前，先測試特殊的debug變量。

對于産生有用的出錯消息而言，tom christiansen提出了下面5條黃金法則：

出錯消息應該送到stderr而不是stdout；

包括釋出該出錯消息的程式名；

說明什麼函數或者操作未成功；

如果一次系統調用失敗，那麼就要包括perror這個字元串（在perl裡是$!）；

用0之外的其他一些出錯碼退出。

perl可以輕易遵守所有5條法則：