Shell腳本書寫規范

在日常的運維工作中，Shell腳本肯定是必不可少的工作內容。為方便問題排查、腳本執行歷史問題追蹤、方便大家共同維護，從網上搜羅結合以往的經驗教訓擬定以下Bash腳本書寫規范。歡迎各位同學指正或補充。

• 代碼風格規范
• 代碼有注釋
• 參數要規范
• 環境變量和魔數
• 變量的定義和引用
• 縮進有規矩
• 命名有標准
• 編碼要統一
• 執行權限記得加
• 日志和回顯
• 太長要分行
• 代碼有效率
• 勤用雙引號
• 巧用main函數
• 考慮作用域
• 巧用heredocs
• 學會查路徑
• 代碼要簡短
• 使用新寫法
• 其他小tip

代碼風格規范

開頭有“蛇棒”
所謂shebang其實就是在很多腳本的第一行出現的以”#!”開頭的注釋，他指明了當我們沒有指定解釋器的時候默認的解釋器，一般可能是下面這樣：

#!/bin/bash

當然，解釋器有很多種，除了bash之外，我們可以用下面的命令查看本機支持的解釋器:

[root@thatsit 00:20:11 ~]# cat /etc/shells
/bin/sh
/bin/bash
/sbin/nologin
/bin/dash
/bin/tcsh
/bin/csh
/usr/bin/tmux
[root@thatsit 00:28:32 ~]#

當我們直接使用./a.sh來執行這個腳本的時候，如果沒有shebang，那么它就會默認用$SHELL指定的解釋器，否則就會用shebang指定的解釋器。

不過，上面這種寫法可能不太具備適應性，一般我們會用下面的方式來指定：

#!/usr/bin/env bash

代碼有注釋

注釋，顯然是一個常識，不過這里還是要再強調一下，這個在shell腳本里尤為重要。因為很多單行的shell命令不是那么淺顯易懂，沒有注釋的話在維護起來會讓人尤其的頭大。
注釋的意義不僅在於解釋用途，而在於告訴我們注意事項，就像是一個README。
具體的來說，對於shell腳本，注釋一般包括下面幾個部分：

1. shebang
2. 腳本的參數
3. 腳本的用途
4. 腳本的用法及注意事項
5. 腳本試用平台
6. 腳本的寫作時間，作者，版權等
7. 各個函數前的說明注釋
8. 一些較復雜的單行命令注釋

簡單腳本頭樣例

#!/bin/bash
#########################################################
# Function :Rotate application logs                     #
# Platform :All Linux Based Platform                    #
# Version  :1.0                                         #
# Date     :2017-07-28                                  #
# Author   :Stephen.Shi                                 #
# Contact  :[e-mail]                                #
# Company  :MeiTu                                       #
#########################################################

參數要規范

這一點很重要，當我們的腳本需要接受參數的時候，我們一定要先判斷參數是否合乎規范，並給出合適的回顯，方便使用者了解參數的使用。
最少，最少，我們至少得判斷下參數的個數吧：

• args judgement 姿勢1

if [[ $# != 2 ]];then
    echo "Parameter incorrect."
    exit 1
fi

• args judgement 姿勢2

# Uasge
help_msg(){
    echo "Usage: $0 <server_group_to_operate>"
}

# arg judge
if [[ $# -ne 1 ]]
then
    help_msg
else
    xxoo_func
fi

環境變量和魔數

一般情況下我們會將一些重要的環境變量定義在開頭，確保這些變量的存在。

source /etc/profile
export PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/apps/bin/"

這種定義方式有一個很常見的用途，最典型的應用就是，當我們本地安裝了很多java版本時，我們可能需要指定一個java來用。那么這時我們就會在腳本開頭重新定義JAVA_HOME以及PATH變量來進行控制。

同時，一段好的代碼通常是不會有很多硬編碼在代碼里的“魔數”的。如果一定要有，通常是用一個變量的形式定義在開頭，然后調用的時候直接調用這個變量，這樣方便日后的修改。

變量的定義和引用

變量的定義和引用需要遵循一定的規范：

1. 名稱長的變量盡量使用駝峰寫法或者使用小寫字母+下划線的方式進行命名
2. 常量的定義推薦使用大寫字母進行命名
3. 在引用變量時為了避免不必要的麻煩，盡量使用${變量名}的方式進行引用

變量名引用的坑的樣例

[root@thatsit scripts]$ cat var_test.sh
#!/bin/bash
xx="heiheihei"
xx_="123"
oo="666"
echo $xx$oo
echo "----"
echo $xx_$oo
echo "----"
echo ${xx}_${oo}
[root@thatsit scripts]$ sh var_test.sh
heiheihei666
----
123666
----
heiheihei_666
[root@thatsit scripts]$

縮進有規矩

對於shell腳本，縮進是個大問題。因為很多需要縮進的地方(比如if,for語句)都不長，所有很多人都懶得去縮進，而且很多人不習慣用函數，導致縮進功能被弱化。
其實正確的縮進是很重要的，尤其是在寫函數的時候，否則我們在閱讀的時候很容易把函數體跟直接執行的命令搞混。
常見的縮進方法主要有”soft tab”和”hard tab”兩種。

• 所謂soft tab就是使用n個空格進行縮進(n通常是2或4)
• 所謂hard tab當然就是指真實的”\t”字符，這里不去撕哪種方式最好，只能說各有各的優劣。反正我習慣用四個空格(美劇《硅谷》中的男主執着於用tab，並因此跟習慣使用空格的女友分手，哈哈)。

命名有標准

所謂命名規范，基本包含下面這幾點：

1. 文件名規范，以.sh結尾，方便識別
2. 通過腳本名稱最好能夠直接讀出腳本的用途，比如常用xx服務的啟動腳本可命名為start_xx.sh，oo服務的監控腳本可命名為oo_monit.sh，告警腳本可名稱為abc_alert.sh
3. 變量名字要有含義，不要拼錯，盡量使用英文，可能顯得更專業(ps:逼格高)一點，哈哈
4. 統一命名風格，用駝峰或者下划線連接，推薦使用小寫字母加下划線的方式

編碼要統一

在寫腳本的時候盡量使用UTF-8編碼，能夠支持中文等一些奇奇怪怪的字符。
盡管腳本中可以寫中文，但是在寫注釋以及打log的時候還是盡量英文，畢竟有些機器還是沒有直接支持中文的，打出來可能會有亂碼。

執行權限記得加

小點，卻非常重要；不加執行權限經常會導致無法直接執行，尤其是init腳本等。

日志和回顯

日志的重要性不必多說，能夠方便我們回頭糾錯，在大型的項目里是非常重要的。
如果這個腳本是供用戶直接在命令行使用的，那么我們最好還要能夠在執行時實時回顯執行過程，方便用戶掌控。
有時候為了提高用戶體驗，可以回顯中添加一些特效，比如顏色啊，閃爍啊之類的，具體可以參考ANSI/VT100 Control sequences這篇文章的介紹。

注意：

1. 一些debug級別的信息，在腳本調試結束后需要關閉。
2. 日志輸出要帶時間、要帶時間、帶時間，在寫定時任務用的腳本時尤為重要。

3. 日志的輸出推薦使用tee -a ${log_file}的方式，可以直接在main函數入口處添加日志輸出。

• 腳本日志輸出樣例

logfile="/var/log/log_clean.log"

# define functions
function xx(){
    echo "xx"
}

function oo(){
    echo "oo"
}

# define main function
function main(){
    xx
    oo
}

# invoke main function
main|tee -a ${logfile}

太長要分行

在調用某些程序的時候，參數可能會很長，這時候為了保證較好的閱讀體驗，我們可以用反斜杠來分行：

./configure \
–prefix=/usr \
–sbin-path=/usr/sbin/nginx \
–conf-path=/etc/nginx/nginx.conf \

注意在反斜杠前有個空格。

代碼有效率

在使用命令的時候要了解命令的具體做法，尤其當數據處理量大的時候，要時刻考慮該命令是否會影響效率。
比如下面的兩個sed命令：

sed -n '1p' file
sed -n '1p;1q' file

他們的作用一樣，都是獲取文件的第一行。但是第一條命令會讀取整個文件，而第二條命令只讀取第一行。當文件很大的時候，僅僅是這樣一條命令不一樣就會造成巨大的效率差異。

當然，這里只是為了舉一個例子，這個例子真正正確的用法應該是使用head -1 file命令。

勤用雙引號

幾乎所有的大佬都推薦在使用$來獲取變量的時候最好加上雙引號。
不加上雙引號在很多情況下都會造成很大的麻煩，為什么呢？舉一個例子：

#!/bin/sh
#已知當前文件夾有一個a.sh的文件
var="*.sh"
echo $var
echo "$var"

他的運行結果如下：

a.sh
*.sh

為啥會這樣呢？其實可以解釋為他執行了下面的命令：

echo *.sh
echo "*.sh"

在很多情況下，在將變量作為參數的時候，一定要注意上面這一點，仔細體會其中的差異。上面只是一個非常小的例子，實際應用的時候由於這個細節導致的問題實在是太多了。

巧用main函數

我們知道，像java，C這樣的編譯型語言都會有一個函數入口，這種結構使得代碼可讀性很強，我們知道哪些直接執行，那些是函數。但是腳本不一樣，腳本屬於解釋性語言，從第一行直接執行到最后一行，如果在這當中命令與函數糅雜在一起，那就非常難讀了。

各位同學應該都寫過python，因此大家都知道一個合乎標准的python腳本大體上至少是這樣的：

#!/usr/bin/env python

def func1():
    pass

def func2():
    pass

if __name__=='__main__':
    func1()
    func2()

他用一個很巧妙的方法實現了我們習慣的main函數，使得代碼可讀性更強。

在shell中，我們也有類似的小技巧:

#!/usr/bin/bash

func1(){
    #do sth
}

func2(){
    #do sth
}

main(){
    func1
    func2
}

main "$@"

我們可以采用這種寫法，同樣實現類似的main函數，使得腳本的結構化程度更好。

另外在傳遞參數的時候可能會遇到參數接收位置的變化，記得使用shift函數。

考慮作用域

shell中默認的變量作用域都是全局的，比如下面的腳本：

#!/usr/bin/env bash

var=1
func(){
    var=2
}
func
echo $var

他的輸出結果就是2而不是1，這樣顯然不符合我們的編碼習慣，很容易造成一些問題。
因此，相比直接使用全局變量，我們最好使用local readonly這類的命令，其次我們可以使用declare來聲明變量。這些方式都比使用全局方式定義要好。

巧用heredocs

所謂heredocs，也可以算是一種多行輸入的方法，即在”<<”后定一個標識符，接着我們可以輸入多行內容，直到再次遇到標識符為止。
使用heredocs，我們可以非常方便的生成一些模板文件：

cat>>/etc/rsyncd.conf << EOF
log file = /usr/local/logs/rsyncd.log
transfer logging = yes
log format = %t %a %m %f %b
syslog facility = local3
EOF

學會查路徑

很多情況下，我們會先獲取當前腳本的路徑，然后一這個路徑為基准，去找其他的路徑。通常我們是直接用pwd以期獲得腳本的路徑。
不過其實這樣是不嚴謹的，pwd獲得的是當前shell的執行路徑，而不是當前腳本的執行路徑。
正確的做法應該是下面這兩種：

script_dir=$(cd $(dirname $0) && pwd)
script_dir=$(dirname $(readlink -f $0 ))

應當先cd進當前腳本的目錄然后再pwd，或者直接讀取當前腳本的所在路徑；之前在編寫nginx配置更新腳本的時候就遇到了這個操作姿勢的坑。

代碼要簡短

這里的簡短不單單是指代碼長度，而是只用到的命令數。原則上我們應當做到，能一條命令解決的問題絕不用兩條命令解決。這不僅牽涉到代碼的可讀性，而且也關乎代碼的執行效率。
最最經典的例子如下：

cat /etc/passwd | grep root
grep root /etc/passwd

cat命令最為人不齒的用法就是這樣，用的沒有任何意義，明明一條命令可以解決，他非得加根管道；並且在處理大文件的時候第一種方式的效率會比較低。

使用新寫法

這里的新寫法不是指有多厲害，而是指我們可能更希望使用較新引入的一些語法，更多是偏向代碼風格的，比如

1. 盡量使用func(){}來定義函數，而不是func{}
2. 盡量使用[[]]來代替[]
3. 盡量使用$()將命令的結果賦給變量，而不是反引號
4. 在復雜的場景下盡量使用printf代替echo進行回顯
5. 事實上，這些新寫法很多功能都比舊的寫法要強大，用的時候就知道了。

其他小tip

考慮到還有很多零碎的點，就不一一展開了，這里簡單提一提。

• 路徑盡量保持絕對路徑，絕多路徑不容易出錯，如果非要用相對路徑，最好用./修飾
• 優先使用bash的變量替換代替awk sed，這樣更加簡短
• 簡單的if盡量使用&&和||，寫成單行。比如[[ x > 2]] && echo x
• 當export變量時，盡量加上子腳本的namespace，保證變量不沖突
• 會使用trap捕獲信號，並在接受到終止信號時執行一些收尾工作
• 使用mktemp生成臨時文件或文件夾
• 利用/dev/null過濾不友好的輸出信息
• 會利用命令的返回值判斷命令的執行情況
• 使用文件前要判斷文件是否存在，否則做好異常處理
• 不要處理ls后的數據(比如ls -l | awk '{ print $8 }')，ls的結果非常不確定，並且平台有關
• 讀取文件時不要使用for loop而要使用while read