来自：Myths的个人博客
作者：myths
链接：https://blog.mythsman.com/2017/07/23/1/
代码风格规范
开头有“蛇棒”
所谓shebang其实就是在很多脚本的第一行出现的以”#!”开头的注释，他指明了当我们没有指定解释器的时候默认的解释器，一般可能是下面这样：
当然，解释器有很多种，除了bash之外，我们可以用下面的命令查看本机支持的解释器:
- #!/bin/$cat/etc/shells
- #/etc/shells:validloginshells
- /bin/sh
- /bin/dash
- /bin/bash
- /bin/rbash
- /usr/bin/screen
当我们直接使用./a.sh来执行这个脚本的时候，如果没有shebang，那么它就会默认用$SHELL指定的解释器，否则就会用shebang指定的解释器。
不过，上面这种写法可能不太具备适应性，一般我们会用下面的方式来指定：
- <spanstyle="background-color:rgb(255,51);"><strong>#!/usr/bin/envbash</strong></span>
这种方式是我们推荐的使用方式。
代码有注释
注释，显然是一个常识，不过这里还是要再强调一下，这个在shell脚本里尤为重要。因为很多单行的shell命令不是那么浅显易懂，没有注释的话在维护起来会让人尤其的头大。
注释的意义不仅在于解释用途，而在于告诉我们注意事项，就像是一个README。
具体的来说，对于shell脚本，注释一般包括下面几个部分：
-
shebang
-
脚本的参数
-
脚本的用途
-
脚本的注意事项
-
脚本的写作时间，作者，版权等
-
各个函数前的说明注释
-
一些较复杂的单行命令注释
参数要规范
这一点很重要，当我们的脚本需要接受参数的时候，我们一定要先判断参数是否合乎规范，并给出合适的回显，方便使用者了解参数的使用。
最少，最少，我们至少得判断下参数的个数吧：
- if[[$#!=2]];then
- echo"Parameterincorrect."
- exit1
- fi
太长要分行
在调用某些程序的时候，参数可能会很长，这时候为了保证较好的阅读体验，我们可以用反斜杠来分行：
- ./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 -n1 file命令。。。
勤用双引号
几乎所有的大佬都推荐在使用”$”来获取变量的时候最好加上双引号。
不加上双引号在很多情况下都会造成很大的麻烦，为什么呢？举一个例子：
- #!/bin/sh
- #已知当前文件夹有一个a.sh的文件
- var="*.sh"
- echo$var
- echo"$var"
他的运行结果如下：
为啥会这样呢？其实可以解释为他执行了下面的命令：
在很多情况下，在将变量作为参数的时候，一定要注意上面这一点，仔细体会其中的差异。上面只是一个非常小的例子，实际应用的时候由于这个细节导致的问题实在是太多了。。。
巧用main函数
我们知道，像Java，C这样的编译型语言都会有一个函数入口，这种结构使得代码可读性很强，我们知道哪些直接执行，那些是函数。但是脚本不一样，脚本属于解释性语言，从第一行直接执行到最后一行，如果在这当中命令与函数糅杂在一起，那就非常难读了。
用Python的朋友都知道，一个合乎标准的python脚本大体上至少是这样的：
- #!/usr/bin/envpython
- deffunc1():
- pass
- deffunc2():
- pass
- if__name__=='__main__':
- func1()
- func2()
他用一个很巧妙的方法实现了我们习惯的main函数，使得代码可读性更强。
在shell中，我们也有类似的小技巧:
- #!/usr/bin/envbash
- func1(){
- #dosth
- }
- func2(){
- #dosth
- }
- main(){
- func1
- func2
- }
- main"$@"
我们可以采用这种写法，同样实现类似的main函数，使得脚本的结构化程度更好。
考虑作用域
shell中默认的变量作用域都是全局的，比如下面的脚本：
- #!/usr/bin/envbash
- var=1
- func(){
- var=2
- }
- func
- echo$var
他的输出结果就是2而不是1，这样显然不符合我们的编码习惯，很容易造成一些问题。
因此，相比直接使用全局变量，我们最好使用local readonly这类的命令，其次我们可以使用declare来声明变量。这些方式都比使用全局方式定义要好。
函数返回值
在使用函数的时候一定要注意，shell中函数的返回值只能是整数，估计是因为一般情况下一个函数的返回值通常表示这个函数的运行状态，所以一般都是0或者是１就够了，因此就设计成了这样。不过，如果非得想传递字符串，也可以通过下面变通的方法:
- func(){
- echo"2333"}
- res=$(func)
- echo"Thisisfrom$res."
这样，通过echo或者print之类的就可以做到传一些额外参数的目的。
间接引用值
什么叫间接引用？比如下面这个场景：
- VAR1="2323232"
- VAR2="VAR1"
我们有一个变量VAR1，又有一个变量VAR2，这个VAR2的值是VAR1的名字，那么我们现在想通过VAR2来获取VAR1的值，这时候应该怎么办呢？
比较土鳖的方法是这样：
这个用法的确可行，但是看起来十分的不舒服，很难只管的去理解，我们并不推荐。而且事实上我们本身就不推荐使用eval这个命令。
通过在变量名前加一个!就可以做到简单的间接引用了。
不过需要注意的是，用上面的方法，我们只能够做到取值，而不能做到赋值。
巧用heredocs
所谓heredocs，也可以算是一种多行输入的方法，即在”<<”后定一个标识符，接着我们可以输入多行内容，直到再次遇到标识符为止。
使用heredocs，我们可以非常方便的生成一些模板文件：
- cat>>/etc/rsyncd.conf<<EOF
- logfile=/usr/local/logs/rsyncd.log
- transferlogging=yes
- logformat=%t%a%m%f%b
- syslogfacility=local3
- EOF
学会查路径
很多情况下，我们会先获取当前脚本的路径，然后一这个路径为基准，去找其他的路径。通常我们是直接用pwd以期获得脚本的路径。
不过其实这样是不严谨的，pwd获得的是当前shell的执行路径，而不是当前脚本的执行路径。
正确的做法应该是下面这两种：
- script_dir=$(cd$(dirname$0)&&pwd)
- script_dir=$(dirname$(readlink-f$0))
应当先cd进当前脚本的目录然后再pwd，或者直接读取当前脚本的所在路径。
代码要简短
这里的简短不单单是指代码长度，而是只用到的命令数。原则上我们应当做到，能一条命令解决的问题绝不用两条命令解决。这不仅牵涉到代码的可读性，而且也关乎代码的执行效率。
最最经典的例子如下：
- cat/etc/passwd|greproot
- greproot/etc/passw
cat命令最为人不齿的用法就是这样，用的没有任何意义，明明一条命令可以解决，他非得加根管道。。。
其实代码简短在还能某种程度上能保证效率的提升，比如下面的例子：
- #method1
- find.-name'*.txt'|xargssed-is/233/666/g
- find.-name'*.txt'|xargssed-is/235/626/g
- find.-name'*.txt'|xargssed-is/333/616/g
- find.-name'*.txt'|xargssed-is/233/664/g
- #method1
- find.-name'*.txt'|xargssed-i"s/233/666/g;s/235/626/g;s/333/616/g;s/233/664/g"
这两种方法做的事情都一样，就是查找所有的.txt后缀的文件并做一系列替换。前者是多次执行find，后者是执行一次find，但是增加了sed的模式串。第一种可读性更好一点，但是当替换的量变大的时候，第二种的速度就会比第一种快很多。这里效率提升的原因，就是第二种只要执行一次命令，而第一种要执行多次。
使用新写法
这里的新写法不是指有多厉害，而是指我们可能更希望使用较新引入的一些语法，更多是偏向代码风格的，比如
尽量使用func(){}来定义函数，而不是func{}
尽量使用[[]]来代替[]
尽量使用$()将命令的结果赋给变量，而不是反引号
在复杂的场景下尽量使用printf代替echo进行回显
事实上，这些新写法很多功能都比旧的写法要强大，用的时候就知道了。
其他小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
静态检查工具shellcheck
概述
为了从制度上保证脚本的质量，我们最简单的想法大概就是搞一个静态检查工具，通过引入工具来弥补开发者可能存在的知识盲点。
市面上对于shell的静态检查工具还真不多，找来找去就找到一个叫shellcheck的工具，开源在github上，有8K多的star，看上去还是十分靠谱的。我们可以去他的主页了解具体的安装和使用信息。
安装
这个工具的对不同平台的支持力度都很大，他至少支持了
Debian,Arch,Gentoo,EPEL,Fedora,OS X,openSUSE等等各种的平台的主流包管理工具。安装方便。具体可以参照安装文档
集成
既然是静态检查工具，就一定可以集成在CI框架里，shellcheck可以非常方便的集成在Travis CI中，供以shell脚本为主语言的项目进行静态检查。
样例
在文档的Gallery of bad code里，也提供了非常详细的“坏代码”的标准，具有非常不错的参考价值，可以在闲下来的时候当成”Java Puzzlers“之类的书来读读还是很惬意的。
本质
不过，其实我觉得这个项目最最精华的部分都不是上面的功能，而是他提供了一个非常非常强大的wiki。在这个wiki里，我们可以找到这个工具所有判断的依据。在这里，每一个检测到的问题都可以在wiki里找到对应的问题单号，他不仅告诉我们”这样写不好”，而且告诉我们”为什么这样写不好”，”我们应当怎么写才好”，非常适合刨根问底党进一步研究。
参考资料
关于 shell 脚本编程的10 个最佳实践
shell脚本编写规范
Shellcheck Tool
Best Practices for Writing Bash Scripts
Good coding practices for bash
Design patterns or best practices for shell scripts
bashstyle(GITHUB)
BashGuide/Practices
Obsolete and deprecated syntax
ANSI/VT100 Control sequences
（编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
