本节书摘来自异步社区《UNIX/Linux 系统管理技术手册（第四版）》一书中的第2章，第2.6节，作者：【美】Evi Nemeth , Garth Snyder , Trent R.Hein , Ben Whaley著，更多章节内容可以访问云栖社区“异步社区”公众号查看
2.6 脚本编程的最佳实践
UNIX/Linux 系统管理技术手册（第四版）
虽然本章里的代码片段几乎不带注释，而且很少打印用法说明，只是因为我们已经列出了每个例子的大纲，从而体现出若干关键点。实际的脚本应该有更好的表现。有几本书通篇就讲编码的最佳实践，不过其中的基本指导原则如下。
如果运行脚本时带了不合适的参数，脚本应该打印一则用法说明，然后再退出。更好的做法是，也以这样的方式实现--help选项。
验证输入的有效性，并检查获得的输入值。例如，在对算出来的一个路径执行rm -fr操作之前，可能要让脚本复查这条路径是否符合期望的模式。此时会发现脚本编程语言的“污点（taint）”功能很有帮助。
返回一个恰当的退出码：0表示成功，非0表示不成功。但是，没有必要非要给每种不成功的模式分配一个唯一的退出码，考虑调用程序实际想要的是什么。
用适当的命名约定来给变量、脚本以及函数起名字。名字要符合该语言的惯例，符合代码库中大部分代码的习惯，最重要的是，符合当前项目里定义的其他变量和函数的惯例。用大小写或者下划线来让长名字可读性更好1。
用变量名反映变量保存的值，但要保持简洁。number_of_lines_of_input这样就太长了；试试用n_lines。
考虑形成一种指导风格，这样一来，你和你的团队成员都可以按照相同的规范来编写代码。有了这样的指导，在阅读别人写的代码，或者别人阅读你写的代码时，都会变得更容易。
每个脚本开头有一段注释，说明该脚本的作用以及它接受的参数。注释里要包括作者的名字和编写日期。如果这个脚本需要在系统上安装非标准的工具、库或者模块，那么也要把它们列出来。
注释要达到的程度是，过一两个月再来看这个脚本，发现注释很有帮助就行了。有关注释的一些要点如下：选择的算法、没有按显然更好的方式去做的理由、代码里不常见的路径，以及在开发期间成为障碍的任何东西。不要到处乱写没用的注释；要假定阅读代码的人不傻，而且熟悉语言。
最好做到代码块级或者函数级的注释。对变量功能的注释说明应该出现在变量声明或者首次使用变量的地方。
以root身份运行脚本是可以的，但要避免设置这些脚本的setuid位；保证setuid的脚本彻底安全相当费事儿。所以代之以用sudo来实现适当的访问控制策略。
对于bash来说，在执行命令之前，先用-x回显命令，用-n检查命令的语法，却不执行它们。
Perl的-w选项可以把某些可疑行为报告给用户，如变量未设置就先使用这样的问题。可以把这个选项加到脚本的“#!”一行里，或者用use warnings打开该程序的文字提示。
在Python中，除非在命令行用-0参数显式地关闭debug（调试）模式，否则就在这个模式下。这意味着，可以在打印诊断输出之前，先测试特殊的debug变量。
对于产生有用的出错消息而言，Tom Christiansen提出了下面5条黄金法则：
出错消息应该送到STDERR而不是STDOUT；
包括发布该出错消息的程序名；
说明什么函数或者操作未成功；
如果一次系统调用失败，那么就要包括perror这个字符串（在Perl里是$!）；
用0之外的其他一些出错码退出。
Perl可以轻易遵守所有5条法则：
die "can’t open $filename: $!";
