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 以外的代码退出。

你可能感兴趣的:(451. 【Unix/Linux 系统管理】脚本编写最佳实践)