451. 【Unix/Linux 系统管理】脚本编写最佳实践

现实中的脚本应该不会这么简陋，下面是一些基本的准则。

• 如果运行时使用的参数有问题，脚本应该打印出用法信息并退出。作为补充，还可以实现 --help选项功能。

• 验证输入，对派生值（derived value）进行合理性检查。例如，在生成的路径上执行 rm -rf 之前，脚本应该再次检查该路径是否符合期望。

• 返回有意义的退出码：0 代表成功，非 0 代表失败。没必要为每一种失败形式都分配一个唯一的退出码，考虑调用方真正想知道什么。

• 为变量、脚本和函数选择合适的命名规范。这些要符合的规范包括语言本身、站点的基础代码、当前项目中定义的其他函数，其中最后一处尤为重要。可以使用混合大小写或下划线提高长名字的可读性。

• 给变量命名时，不仅要能够反映其所存储的值，还要保持简洁。number_of_lines_of_input 这个名字就太长了，可以试试 n_lines。

• 考虑编写一套编码风格指南，以便你和你的同事能够按照同样的规范编写代码。指南可以让大家更容易阅读彼此的代码。

• 每个脚本开头都加上一段注释，说明该脚本的用途以及所接受的参数。别忘了加上你的名字和编写日期。如果脚本要求系统中安装非标准工具、库或模块，也要在此注明。

• 应该保证当一两个月后再阅读脚本时，当时写下的注释有助于你理解代码意图。下面是一些有用的注释书写建议：所选择的算法、用到的 Web 参考页面、为什么不使用其他更为显而易见的处理方法、不常见的代码流程、开发过程中出现的问题。

• 不要堆砌带有无用注释的代码，要假定代码阅读人员的理解能力不差并且熟悉该语言。

• 以 root 身份运行脚本没有问题，但是不要为脚本设置 setuid，完全确保 setuid 脚本的安全性不是件容易事。应该使用 sudo 实现相应的访问控制策略。

• 自己不明白的地方就不要写代码。管理员经常会浏览脚本，将其视为如何处理特定过程的全文文档。不要去散布那些不成熟的脚本，搞出些误导他人的例子。

• 可以随意改造自己的脚本中的代码以满足自己的需要。但如果你不理解代码的含义，可别陷入到这种“复制，粘贴，然后祈祷”的编程方式中。花点时间把代码缕清，这些时间绝不会白费。

• 通过 bash 选项，使用 -x 选项以在执行命令之前回显命令，使用 -n 选项可以在不执行命令的情况下检查命令的语法。

5 条生成有用错误信息的黄金法则

1. 错误信息应该进入 STDERR，而不是 STDOUT。
2. 包括发生该程序的程序名。
3. 说明哪个函数或操作未成功。
4. 如果系统调用失败，要包括函数 perror() 的输出。

• 使用 0 以外的代码退出。