由于工作需要，最近重新开始拾掇shell脚本。虽然绝大部分命令自己平时也经常使用，但是在写成脚本的时候总觉得写的很难看。而且当我在看其他人写的脚本的时候，总觉得难以阅读。毕竟shell脚本这个东西不算是正经的编程语言，他更像是一个工具，用来杂糅不同的程序供我们调用。

因此很多人在写的时候也是想到哪里写到哪里，基本上都像是一段超长的main函数，不忍直视。同时，由于历史原因，shell有很多不同的版本，而且也有很多有相同功能的命令需要我们进行取舍，以至于代码的规范很难统一。

考虑到上面的这些原因，我查阅了一些相关的文档，发现这些问题其实很多人都考虑过，而且  也形成了一些不错的文章，但是还是有点零散。因此我就在这里把这些文章稍微整理了一下，作为以后我自己写脚本的技术规范。

代码风格规范

开头有“蛇棒”

所谓shebang其实就是在很多脚本的第一行出现的以#!开头的注释，他指明了当我们没有指定解释器的时候默认的解释器，一般可能是下面这样：

1. #!/bin/bash 

当然，解释器有很多种，除了bash之外，我们可以用下面的命令查看本机支持的解释器:

1. $ cat /etc/shells  
2. #/etc/shells: valid login shells  
3. /bin/sh  
4. /bin/dash  
5. /bin/bash  
6. /bin/rbash  
7. /usr/bin/screen 

当我们直接使用./a.sh来执行这个脚本的时候，如果没有shebang，那么它就会默认用$SHELL指定的解释器，否则就会用shebang指定的解释器。

这种方式是我们推荐的使用方式。

代码有注释

注释，显然是一个常识，不过这里还是要再强调一下，这个在shell脚本里尤为重要。因为很多单行的shell命令不是那么浅显易懂，没有注释的话在维护起来会让人尤其的头大。

注释的意义不仅在于解释用途，而在于告诉我们注意事项，就像是一个README。

具体的来说，对于shell脚本，注释一般包括下面几个部分：

•  shebang
•  脚本的参数
•  脚本的用途
•  脚本的注意事项
•  脚本的写作时间，作者，版权等
•  各个函数前的说明注释
•  一些较复杂的单行命令注释

参数要规范

这一点很重要，当我们的脚本需要接受参数的时候，我们一定要先判断参数是否合乎规范，并给出合适的回显，方便使用者了解参数的使用。