正文
现实中的脚本应该不会这么简陋，下面是一些基本的准则。
- 如果运行时使用的参数有问题，脚本应该打印出用法信息并退出。作为补充，还可以实现
--help选项功能。
- 验证输入，对派生值（derived value）进行合理性检查。例如，在生成的路径上执行
rm -rf之前，脚本应该再次检查该路径是否符合期望。
- 返回有意义的退出码：0 代表成功，非 0 代表失败。没必要为每一种失败形式都分配一个唯一的退出码，考虑调用方真正想知道什么。
- 为变量、脚本和函数选择合适的命名规范。这些要符合的规范包括语言本身、站点的基础代码、当前项目中定义的其他函数，其中最后一处尤为重要。可以使用混合大小写或下划线提高长名字的可读性。
- 给变量命名时，不仅要能够反映其所存储的值，还要保持简洁。number_of_lines_of_input 这个名字就太长了，可以试试 n_lines。
- 考虑编写一套编码风格指南，以便你和你的同事能够按照同样的规范编写代码。指南可以让大家更容易阅读彼此的代码。
- 每个脚本开头都加上一段注释，说明该脚本的用途以及所接受的参数。别忘了加上你的名字和编写日期。如果脚本要求系统中安装非标准工具、库或模块，也要在此注明。
- 应该保证当一两个月后再阅读脚本时，当时写下的注释有助于你理解代码意图。下面是一些有用的注释书写建议：所选择的算法、用到的 Web 参考页面、为什么不使用其他更为显而易见的处理方法、不常见的代码流程、开发过程中出现的问题。
- 不要堆砌带有无用注释的代码，要假定代码阅读人员的理解能力不差并且熟悉该语言。
- 以 root 身份运行脚本没有问题，但是不要为脚本设置 setuid，完全确保 setuid 脚本的安全性不是件容易事。应该使用 sudo 实现相应的访问控制策略。
- 自己不明白的地方就不要写代码。管理员经常会浏览脚本，将其视为如何处理特定过程的全文文档。不要去散布那些不成熟的脚本，搞出些误导他人的例子。
- 可以随意改造自己的脚本中的代码以满足自己的需要。但如果你不理解代码的含义，可别陷入到这种“复制，粘贴，然后祈祷”的编程方式中。花点时间把代码缕清，这些时间绝不会白费。
- 通过 bash 选项，使用 -x 选项以在执行命令之前回显命令，使用 -n 选项可以在不执行命令的情况下检查命令的语法。
5 条生成有用错误信息的黄金法则
- 错误信息应该进入 STDERR，而不是 STDOUT。
- 包括发生该程序的程序名。
- 说明哪个函数或操作未成功。
- 如果系统调用失败，要包括函数 perror() 的输出。
- 使用 0 以外的代码退出。
