接触SHELL脚本编程时间不长，在工作过程中发现，SHELL脚本（以下简称脚本）的内容无论从命名还是组织结构，都很混乱。编码人员随便写，怎么爽怎么来。维护人员头大，看不懂的地方，就通过if ... else ...绕过去。或者，增加新的补丁，一层一层。日复一日，年复一年，代码变得臃肿不堪，没人敢动手。命令的可读性差，让初学者无从下手。一般对命令的学习，也并不是系统性。这些都是脚本编程的问题源泉。能否通过以下的方法来避免这些问题呢？
尽量减少脚本长度
一个脚本文件，文件行数超过100行，看起来就非常费劲了。如果可以的话，尽量将所有的脚本文件都控制在100行以内。
尽量减少脚本功能范围
我们借鉴其他编程语言的经验，可以将每个脚本的功能范围做好限定，避免一个脚本中过多的功能。
尽量减少脚本的传入参数
脚本传入参数可以让脚本实现不同的功能，以此达成脚本内代码的重用。正如上面所述，任何情况下都应该尽量缩减脚本的功能范围。如果有可能，一个脚本仅实现一种业务场景。以此避免脚本的参数调用。
./do_business.sh
./do_business.sh $VAR1 $VAR2 $VAR3
脚本文件名与脚本功能项匹配
每个脚本可以看成是一个函数，在编写脚本时应尽可能的将脚本功能与脚本文件名匹配对应。这样，既可以增加可读性，也可以从业务逻辑上对脚本进行更好的解耦与功能分割。
./init.sh
./init_ubuntu_build_environment.sh
编写脚本注释
脚本头部的注释非常重要，如果脚本可以接受输入参数，应该描述每个参数的功能。
#功能描述：描述脚本实现的业务功能。
#传入参数：描述传入脚本的每个参数功能和影响。
#全局变量：描述脚本需要依赖哪些全局变量？执行脚本后，会改变哪些全局变量？
提炼常用函数并放在公共脚本
针对经常使用的函数，可以将其提炼后放在公共的脚本中，使用时引入该公共脚本即可。
例如：字符串处理、文件处理、目录处理、日期与时间处理、日志处理等。这些常用的功能，通过函数封装的方式，既可以增加脚本的可读性，提高封装性、减少耦合度以及可能的错误。
公共脚本中，应禁止使用任何的系统变量。
函数应传入“输出参数变量名”来实现输出参数
由于SHELL函数无法返回整型除之外的值，所以调用函数时，传出函数的返回值变得较为困难。
为保证函数在调用过程中可重入性，应该避免通过全局变量的方式给函数传递参数。
而应该使用传入参数和传出参数，实现函数功能的调用。
在函数内部，应该使用局部变量：local修饰。
# 功能：实现字符串连接
# 输入$1：字符串1
# 输入$2：字符串2
# 输出：结果字符串
function string_add()
{
local s1=$1
local s2=$2
local result_name=$3
${!result_name}=$(echo $s1$2)
}
编写函数注释
与脚本注释类似，经常调用的函数，也需要增加注释说明，减少调用者的歧义。
